Looking at the CPAN Testers reports: - many FAILs from t/bigmem.t running because AUTOMATED_TESTING is not set - fails for 'long double' perls as reported by Rob - some UNKNOWN from compiler error for FreeBSD 10.1-release
With a fix for long double and making t/bigmem.t run on request only should resolve most of the test failures reported so far. --Chris On 9/30/2015 06: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
