I see two options:
1/ making PDL_D a general fallback and avoid croaking at all like this:
int pdl_whichdatatype_double (NV nv) {
TESTTYPE(PDL_F, PDL_Float)
return PDL_D; /* we do not have anything better than PDL_D at the
moment */
}
2/ implement PDL_LD support (perhaps not in 2.014)
Anyway, for those who are brave enough and want to experiment I have
prepared 64bit strawberry perl portable built with USE_LONG_DOUBLE -
http://strawberryperl.com/beta.html
--
kmx
On 30.9.2015 12:53, Chris Marshall wrote:
> Adding a case to allow "long double" to "double"
> before the croak should fix the problem.
>
> Recommendations?
>
> --Chris
>
> On 9/30/2015 06:49, Chris Marshall wrote:
>> Hi Rob-
>>
>> Thanks for the reports. This did not occur for
>> PDL-2.013 because the logic for 64bit index support
>> was not complete. What I think is happening is
>> that perl values are being converted in the
>> typemap which assumes that PDL_Double is capable
>> of representing any floating point type.
>>
>> For the case of long double -> double conversion,
>> this is not the case. I don't think we want to
>> try to add long double to the PDL-2.x types but
>> we do need to decide how to handle the conversion
>> process and possible loss of precision or range.
>>
>> --Chris
>>
>> On 9/30/2015 04:23,[email protected] wrote:
>>> -----Original Message----- From:[email protected]
>>> Sent: Wednesday, September 30, 2015 11:28 AM
>>> To: Chris Marshall ; perldl
>>> Subject: Re: [Pdl-general] CHM/PDL-2.013_01.tar.gz uploaded to CPAN
>>>
>>>> There's also problems with my long double builds of perl on Windows.
>>> No problems when nvtype is "double".
>>>
>>> 45 of the test scripts are failing because whichdatatype_double(),
>>> which is found in Basic/Core/pdlcore.c, croaks when called with an
>>> argument whose finite floating point decimal value cannot be
>>> expressed exactly in base 2.:
>>>
>>> Something's gone wrong: 0.000000 cannot be converted by
>>> whichdatatype_double at C:\sisyphusion\PDL-2.013_01\blib\lib/PDL/
>>>
>>> (The arg is not zero - it's just that "%lf" does not display the
>>> correct value.)
>>>
>>> whichdatatype_double looks like:
>>>
>>> ##########################
>>> int pdl_whichdatatype_double (NV nv) {
>>> TESTTYPE(PDL_F,PDL_Float)
>>> TESTTYPE(PDL_D,PDL_Double)
>>>
>>> if( !finite(nv) ) { return PDL_D; }
>>> croak("Something's gone wrong: %lf cannot be converted by
>>> whichdatatype_double",
>>> nv);
>>> }
>>> ##########################
>>>
>>> where TESTTYPE is defined as:
>>> #define TESTTYPE(b,a) {a foo = nv; if(nv == foo) return b;}
>>>
>>> Given that PDL_Float is 4 bytes, PDL_Double is 8 bytes and NV is 16
>>> bytes, it should come as no surprise that TESTTYPE should fail to
>>> return for any finite floating point decimal value that cannot be
>>> expressed exactly in base 2.
>>>
>>> However, the reason that 2.013 succeeds for nvtype='long double' is
>>> that whichdatatype_double() simply does NOT get called at any stage
>>> (during the running of its test suite, at least) .
>>>
>>> So ... the question becomes "Why does the PDL-2.013_01 test suite
>>> call whichdatatype_double() at least 45 times when the nvtype is
>>> 'long double' ?"
>>>
>>> This is not a Windows-only issue. There aren't many cpan-testers
>>> running -Duselongdouble builds, but there's a report from one at:
>>> http://www.cpantesters.org/cpan/report/3b328b0e-66d3-11e5-a1a3-e32696b0373b
>>>
>>>
>>> and the same thing is happening there.
>>>
>>> Cheers,
>>> Rob
> ------------------------------------------------------------------------------
> _______________________________________________
> pdl-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pdl-general
>
------------------------------------------------------------------------------
_______________________________________________
pdl-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
