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
