[Numpy-discussion] optimizing power() for complex and real cases
Tim Hochberg
tim.hochberg at cox.net
Wed Feb 15 16:42:02 CST 2006
Gary Ruben wrote:
> Tim Hochberg wrote:
> <big snip>
>
>> As I've been thinking about this some more, I think the correct thing
>> to do is not to mess with the power ufuncs at all. Rather in
>> x.__pow__ (since I don't know that there's anywhere else to do it),
>> after the above checks check the types of the array and in the cases
>> where the first argument is a float or complex and the second
>> argument is some sort of integer array. This would be dispatched to
>> some other helper function instead of the normal pow_ufunc. In other
>> words, optimize:
>>
>> A**2, A**2.0, A**(2.0+0j), etc
>>
>> and
>>
>> A**array([1,2,3])
>>
>> but not
>>
>> A**array[1.0, 2.0, 3.0]
>>
>> I think that this takes care of the optimization slowing down power
>> for general floats and optimizes the only array-array case that
>> really matter.
>
>
> I think this might still be a tiny bit dangerous despite not observing
> monotonicity problems and would be a bit more conservative and change
> it to:
>
> optimize:
>
> A**2, A**(2+0j), etc
I'm guessing here that you did not mean to include (2+0j) on both lists
and that, in fact you wanted not to optimize on complex exponents:
.
So, optimize:
A**-1, A**0, A**1, A**2, etc.
>
> and
>
> A**array([1,2,3])
>
> but not
>
> A**array[1.0, 2.0, 3.0], A**2.0, A**(2.0+0j)
That makes sense. It's safer and easier to explain: "numpy optimizes
raising matrices (and possibly scalars) to integer powers)". The only
sticking point that I see is if David is still interested in optimizing
A**0.5, that's not going to mesh with this. On the other hand, perhaps
he can be persuaded that sqrt(A) is just as good. After all, it's only
one more character long ;)
-tim
More information about the Numpy-discussion
mailing list