Doug Hunt wrote:
> 
> 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 long-standing rule, 
> but I think it would be sensible.  It breaks one test in conv.t that was 
> specifically designed to verify this behavior--that test would have to 
> be changed.

The problem with this is it could force datatype
conversions with dramatic memory consequences, e.g.

$im = zeros(512,256)->byte;    # 128KiB data
$im = $im + 1;                 #   1MiB data now if 1 is double!

> 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?

I'm not sure what the best fix is but the results should
at least be consistent across the different functions.
Since 1. is a float in C, the float output seems plausible
but perhaps violating the rule of least surprise.  There
may be something on this in earlier perldl and pdl-porters
archives, maybe before my time...  :-)

--Chris

_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to