Chris: On Fri, 12 Dec 2008, Chris Marshall wrote:
> 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! '1' would not be double with this fix, just '1.' The difference is that 1. would be treated as double, not float. Your point is well taken, though--there could be some memory consequences in the float vs. double case. > >> 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... :-) I think at least acos(1) should equal acos(1.), but maybe 1. should continue to be float. The trouble is that sometimes (most times) PDL prefers double, just not in this one instance. For example, acos(1) chooses to promote the result to double, not float. $p = pdl(1) yields a double PDL. Lets think about this some more. In going through the PP and Core code to track this down, I was struck at how crufty some of this has become. It would be good to try and simplify the code some. A lot of ambitious and partially completed stuff got added long ago, much of which is not needed. Regards, Doug > > --Chris > ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
