[Numpy-discussion] Re: indexing problem

[Tim Hochberg]

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