[Numpy-discussion] Integers to integer powers, let's make a decision

Nathaniel Smith njs at pobox.com
Mon Jun 13 14:50:25 EDT 2016


On Jun 13, 2016 10:54 AM, "Marten van Kerkwijk" <m.h.vankerkwijk at gmail.com>
wrote:
>
> Hi All,
>
> ​I think we're getting a little off the rails, perhaps because two
questions are being conflated:
>
> 1. What in principle is the best return type for int ** int (which Josef
I think most properly rephrased as whether `**` should be thought of as a
float operator, like `/` in python3 and `sqrt` etc.);
>
> 2. Whether one is willing to possibly break code by implementing this.
>
> My sense is that most discussion is about (1), where a majority may well
agree the answer is float, instead of about (2), where it ends up boiling
down to a judgment call of "eternal small pain" or "possible short-time big
pain but consistency from now on".
>
> Perhaps I can introduce an alternative (likely shot down immediately...).
For this, note that for division at least, numpy follows python closely, so
that one has the following in python2:
> ```
> In [2]: np.arange(10) / 2
> Out[2]: array([0, 0, 1, 1, 2, 2, 3, 3, 4, 4])
>
> In [3]: from __future__ import division
>
> In [4]: np.arange(10) / 2
> Out[4]: array([ 0. ,  0.5,  1. ,  1.5,  2. ,  2.5,  3. ,  3.5,  4. ,
4.5])
> ```
> Since negative exponents are really just  1 over the positive one, could
we use the same logic for **? I.e., let what type is returned by int1 **
int2 be the same as that returned by int1 / int2?

There isn't any reasonable way for numpy's ** operator to check whether the
caller has future division enabled, so I think this proposal boils down to,
int ** int returning int in py2 and float on py3? It has a certain
Solomonic appeal, in that I think it would make everyone equally unhappy
:-). But probably now is not the time to be introducing new py2/py3
incompatibilities...

> If we then also ensure that for integer output type, int1 ** -int2
returns 1 // (int1 ** int2), we have well-defined rules all around, so
there would be no need for raising zero-division error.

Not sure what to make of this part -- converting int ** -int into 1 // (int
** int) will return zero in almost all cases, is the unfortunate behavior
that kicked off this whole discussion. AFAICT everyone agrees that we don't
want *that*. And I don't think this gets around the need to decide how to
handle 0 ** -1, whether by raising ZeroDivisionError or what.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160613/e3c3bdc0/attachment.html>


More information about the NumPy-Discussion mailing list