[Numpy-discussion] Integers to integer powers

Charles R Harris charlesr.harris at gmail.com
Fri May 20 14:35:47 EDT 2016


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.

<snip>

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


More information about the NumPy-Discussion mailing list