[Numpy-discussion] Re: indexing problem
Tim Hochberg
tim.hochberg at cox.net
Mon Feb 13 15:05:05 CST 2006
>>
>>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 <ryanlists at gmail.com> 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
More information about the Numpy-discussion
mailing list