f branch as it
currently is by rebasing it to get rid of the merge commit.
Chris, kmx, any objections?
Ed
*From:*Chris Marshall <mailto:devel.chm...@gmail.com>
*Sent:*Monday, August 31, 2015 10:58 AM
*To:*pdl-devel@lists.sourceforge.net
<mailto:pdl-devel@lists.sourceforge.net>
*
t to get rid of the merge commit.
>
> Chris, kmx, any objections?
>
> Ed
>
> *From:* Chris Marshall
> *Sent:* Monday, August 31, 2015 10:58 AM
> *To:* pdl-devel@lists.sourceforge.net
> *Subject:* Re: [Pdl-devel] LongLong precision (fixed)
>
> The LongLong to Double
it to get rid of the merge commit.
Chris, kmx, any objections?
Ed
*From:* Chris Marshall <mailto:devel.chm...@gmail.com>
*Sent:* Monday, August 31, 2015 10:58 AM
*To:* pdl-devel@lists.sourceforge.net
<mailto:pdl-devel@lists.sourceforge.net>
*Subject:* Re: [Pdl-devel] LongLong
Chris, kmx, any objections?
>
> Ed
>
> *From:* Chris Marshall
> *Sent:* Monday, August 31, 2015 10:58 AM
> *To:* pdl-devel@lists.sourceforge.net
> *Subject:* Re: [Pdl-devel] LongLong precision (fixed)
>
> The LongLong to Double conversion problems
> appear to have been r
The LongLong to Double conversion problems
appear to have been resolved. I would invite
any PDL developers with systems having lots
of RAM to test large memory operations.
We need to add some tests to check for correct
operation when the PDLs and index values are
>=2**31. For instance, here is
-devel@lists.sourceforge.net
Subject: Re: [Pdl-devel] LongLong precision (fixed)
The LongLong to Double conversion problems
appear to have been resolved. I would invite
any PDL developers with systems having lots
of RAM to test large memory operations.
We need to add some tests to check for correct
The LongLong to Double conversion problems
appear to have been resolved. I would invite
any PDL developers with systems having lots
of RAM to test large memory operations.
We need to add some tests to check for correct
operation when the PDLs and index values are
>=2**31. For instance, here is
Hi all,
After some off-list discussion with Chris I have fixed his fix in
longlong-double-fix branch. It seems to work, passes all tests and is more
or less ready for merging to master.
Travis-CI is all green see https://travis-ci.org/PDLPorters/pdl/builds/77348194
All changes:
https://gith
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
16 matches
Mail list logo
