[Numpy-discussion] Integers to integer powers

[Charles R Harris]

On Fri, May 20, 2016 at 12:35 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> On Thu, May 19, 2016 at 9:30 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> So I guess what makes this tricky is that:
>>
>> - We want the behavior to the same for multiple-element arrays,
>> single-element arrays, zero-dimensional arrays, and scalars -- the
>> shape of the data shouldn't affect the semantics of **
>>
>> - We also want the numpy scalar behavior to match the Python scalar
>> behavior
>>
>> - For Python scalars, int ** (positive int) returns an int, but int **
>> (negative int) returns a float.
>>
>> - For arrays, int ** (positive int) and int ** (negative int) _have_
>> to return the same type, because in general output types are always a
>> function of the input types and *can't* look at the specific values
>> involved, and in specific because if you do array([2, 3]) ** array([2,
>> -2]) you can't return an array where the first element is int and the
>> second is float.
>>
>> Given these immutable and contradictory constraints, the last bad
>> option IMHO would be that we make int ** (negative int) an error in
>> all cases, and the error message can suggest that instead of writing
>>
>>     np.array(2) ** -2
>>
>> they should instead write
>>
>>     np.array(2) ** -2.0
>>
>> (And similarly for np.int64(2) ** -2 versus np.int64(2) ** -2.0.)
>>
>> Definitely annoying, but all the other options seem even more
>> inconsistent and confusing, and likely to encourage the writing of
>> subtly buggy code...
>>
>> (I especially have in mind numpy's habit of silently switching between
>> scalars and zero-dimensional arrays -- so it's easy to write code that
>> you think handles arbitrary array dimensions, and it even passes all
>> your tests, but then it fails when someone passes in a different shape
>> data and triggers some scalar/array inconsistency. E.g. if we make **
>> -2 work for scalars but not arrays, then this code:
>>
>> def f(arr):
>>     return np.sum(arr, axis=0) ** -2
>>
>> works as expected for 1-d input, tests pass, everyone's happy... but
>> as soon as you try to pass in higher dimensional integer input it will
>> fail.)
>>
>>
> Hmm, the Alexandrian solution. The main difficulty with this solution that
> this will likely to break working code. We could try it, or take the safe
> route of raising a (Visible)DeprecationWarning. The other option is to
> simply treat the negative power case uniformly as floor division and raise
> an error on zero division, but the difference from Python power would be
> highly confusing. I think I would vote for the second option with a
> DeprecationWarning.
>
>
I suspect that the different behavior of int64 on my system is due to
inheritance from Python 2.7 int

In [1]: isinstance(int64(1), int)
Out[1]: True

That different behavior is also carried over for Python 3.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160520/492f0300/attachment.html>