From: Doug Hunt <dhunt@uc...>  20081213 01:08:07

Hi all: When testing the new PDL interface to plplot, we came across this odd PDL behavior: use PDL; print "acos(1.) = ", acos(1.), "\n"; print "acos(1 ) = ", acos(1 ), "\n"; The acos(1.) version incorrectly gives a single precision result, whereas the acos(1) version gives the expected double precision result. This is due to the fact that there is no integer version of acos and PP routines default to 'double' instead of float in this case. This stems from the fact that: perldl> p PDL::get_datatype(1.) 5 # $PDL_F Which seems oddmost PDL operations default to double precision. After a bit of digging with gdb, it turns out this is caused by: From: pdlcore.c.PL /* Check minimum, at least float, datatype required to represent number */ int pdl_whichdatatype_double (double 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); } So, I would like to propose one of two remedies (attached). The first (pdlcore.c.PL.diff) would be to get rid of pdl_whichdatatype_double and just assume that scalars convert to doubles, not floats. This would be a change to a longstanding rule, but I think it would be sensible. It breaks one test in conv.t that was specifically designed to verify this behaviorthat test would have to be changed. Another approach would be to leave the 'PDL::get_datatype(1.) == $PDL_F' problem alone and just fix 'acos' and the rest of the math functions that can return either float or double values. The other attached patch (math.pd.diff) just changes GenericTypes => ['F', 'D'] to GenericTypes => ['D', 'F'] in several pp_def calls. This has less impact, but solves the irksome 'acos(1.) != acos(1)' problem without changing the fact that '1.' defaults to 'float' instead of 'double'. I've tested both of these out and (with the exception of the conv.t test) they both pass the test suite and solve the problem. Any ideas on which approach to take? Regards, Doug dhunt@... Software Engineer IV UCAR  COSMIC, Tel. (303) 4972611 