|
From: Tim H. <tim...@co...> - 2006-02-13 23:05:00
|
>> >>Ryan Krauss wrote: >> >> >> >>>This may only be a problem for ridiculously large numbers. I actually >>>meant to be dealing with these values: >>> >>>In [75]: d >>>Out[75]: >>>array([ 246.74011003, 986.96044011, 2220.66099025, 3947.84176044, >>> 6168.50275068, 8882.64396098, 12090.26539133, 15791.36704174, >>> 19985.94891221, 24674.01100272]) >>> >>>In [76]: s=d[-1]*1.0j >>> >>>In [77]: s >>>Out[77]: 24674.011002723393j >>> >>>In [78]: type(s) >>>Out[78]: <type 'complex128scalar'> >>> >>>In [79]: s**2 >>>Out[79]: (-608806818.96251547+7.4554869875188623e-08j) >>> >>>So perhaps the previous difference of 26 orders of magnitude really >>>did mean that the imaginary part was negligibly small, that just got >>>obscured by the fact that the real part was order 1e+135. >>> >>>On 2/13/06, Ryan Krauss <rya...@gm...> wrote: >>> >>> I got myself all tied up in a knot over this because I couldn't figure out how multiplying two purely complex numbers was going to result in something with a complex portion. Since I couldn't find the complex routines my imagination went wild: perhaps, I thought, numpy uses the complex multiplication routine that uses 3 multiplies instead of the more straightforward one that uses 4 multiples, etc, etc. None of these panned out, and of course they all evaporated when I got pointed to the code that implements this which is pure vanilla. All the time I was overlooking the obvious: Ryan is using s**2, not s*s. So the obvious answer, is that he's just seeing normal error in the function that is implementing pow. If this is inacuracy is problem, I'd just replace s**2 with s*s. It will probably be both faster and more accurate anyway Foolishly, -tim |