Well, I am not an expert on C but if we have:
typedef long long PDL_LongLong;
typedef double PDL_Anyval;
then after an assignment like this:
anyval_variable = (PDL_Anyval) longlong_variable;
the game is inevitably over (I think) as there is no way how to "recover"
exactly all 64 bits of
Hi kmx-
This the sf bug #343, "longlong constructor and display lose digits
due to implicit double precision conversions" And is the main remaining
issue with 64bit index support.
The PDL_Anyval type is a union type for all the basic PDL types with
64bit integers as well. I've gotten a lot of t
Patching Core.xs improved situation slightly but I have found another
problem in pdlsections.c / pdl_at()
PDL_Anyval pdl_at( void* x, int datatype, PDL_Indx* pos, PDL_Indx* dims,
PDL_Indx* incs, PDL_Indx offset, int ndims)
{
case PDL_LL:
{
PDL_LongLong *xx = (PDL_Lon
Yes, any integer that fits to IV should be converted via newSViv
BTW meanwhile I have found in Core.xs SET_RETVAL_NV macro:
#define SET_RETVAL_NV(x) x->datatype: (RETVAL=newSVnv( result ))
we would need something like
#define SET_RETVAL_NV(rv,val,x) x->datatype: (rv=newSVnv((val)))
but basi
I imagine it would be any int type, no?
On Fri, Aug 21, 2015 at 9:21 AM kmx wrote:
> You are right, at least during unpdl() all values are converted to perl's
> NV
>
> It happens in Core.xs inside SV *listref_c(x) - there is in all cases
> (apart from badval): sv = newSVnv( pdl_val )
>
> Correct
You are right, at least during unpdl() all values are converted to perl's NV
It happens in Core.xs inside SV *listref_c(x) - there is in all cases
(apart from badval): sv = newSVnv( pdl_val )
Correct me if I'm wrong but the patch is quite straightforward
if ( datatype == PDL_LongLong && sizeo
Hi,
as far as I remember, all data gets converted into double during pdl
construction before cast to the desired type. Apparently, unpdl does the
same. It's a known issue for a long time, AFAIK. The same even happens
when you assign to a longlong pdl. If I remember, nobody dared touch the
core har
Hi,
while playing with LongLong piddles representing timestamps I have run into
the following troubles with precision loss when passing 64bit signed int
values between perl and PDL (both directions).
Let's have 64bit number 2534023007 (BTW it is a number of
microseconds since UNIX ep
