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<PDL_F ? (RETVAL=newSViv( (IV)result ))
: (RETVAL=newSVnv( result ))
we would need something like
#define SET_RETVAL_NV(rv,val,x) x->datatype<PDL_F ? (rv=newSViv((IV)(val)))
: (rv=newSVnv((val)))
but basically this is it
--
kmx
On 21.8.2015 16:26, Joel Berger wrote:
I imagine it would be any int type, no?
On Fri, Aug 21, 2015 at 9:21 AM kmx <k...@atlas.cz <mailto:k...@atlas.cz>>
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 me if I'm wrong but the patch is quite straightforward
if ( datatype == PDL_LongLong && sizeof(IV) == 8) {
sv = newSViv( pdl_val );
}
else {
sv = newSVnv( pdl_val );
}
or not?
--
kmx
On 21.8.2015 13:52, Ingo Schmid wrote:
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 hard enough to fix that one, yet.
Ingo
On 08/21/2015 12:55 PM, kmx wrote:
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 253402300799999999 (BTW it is a number of
microseconds since UNIX epoch beginning corresponding to
9999-12-31T23:59:59.999999Z) - it occupies "only" 58bits, so we are
not even approaching 63bit edge which might become tricky when
dealing with 64bit signed integers.
Demonstration code:
use PDL;
use Config;
my $perl_var = 253402300799999999;
my $pdl_var = longlong(253402300799999999);
print "PDL::VERSION: ", $PDL::VERSION, "\n";
print "ivsize : ", $Config{ivsize}, "\n";
print "use64bitint : ", $Config{use64bitint}, "\n";
print "archname : ", $Config{archname}, "\n";
print "perl 1: ", $perl_var, "\n";
print "perl 2: ", ($perl_var % 1000), "\n";
print "pdl : ", $pdl_var->info, "\n";
print "pdl 1: ", $pdl_var, "\n";
print "pdl 2: ", ($pdl_var % 1000), "\n";
print "pdl 3: ", $pdl_var->unpdl->[0], "\n";
Output:
PDL::VERSION: 2.011
ivsize : 8
use64bitint : define
archname : MSWin32-x86-multi-thread-64int
perl 1: 253402300799999999
perl 2: 999
pdl : PDL: LongLong D []
pdl 1: 253402300800000000
pdl 2: 0
pdl 3: 2.534023008e+017
From my point of view there are 2 issues:
1/ A completely legal / not even extremely large / 64bit integer
value is OK on perl side, but when turned into a piddle the value
changes (253402300799999999 > 253402300800000000). This may be a bug.
2/ When exporting a LongLong piddle via unpdl the value (64bit
signed int) is converted into double (perl's NV) even when the perl
is compiled with 64bit integers. Maybe unpdl() is not the best way
for extracting piddle value into a perl array (but I really like
this function :).
Thanks in advance for any hints.
--
kmx
------------------------------------------------------------------------------
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
<mailto:pdl-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pdl-devel
------------------------------------------------------------------------------
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net <mailto:pdl-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pdl-devel
------------------------------------------------------------------------------
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net <mailto:pdl-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/pdl-devel
------------------------------------------------------------------------------
_______________________________________________
pdl-devel mailing list
pdl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pdl-devel
