> On Sun, Oct 9, 2016 at 12:59 PM, Stephan Hoyer <shoyer(a)gmail.com> wrote:
>> I agree with Sebastian and Nathaniel. I don't think we can deviating from
>> the existing behavior (int ** int -> int) without breaking lots of existing
>> code, and if we did, yes, we would need a new integer power function.
>> I think it's better to preserve the existing behavior when it gives
>> sensible results, and error when it doesn't. Adding another function
>> float_power for the case that is currently broken seems like the right way
>> to go.
I actually suspect that the amount of code broken by int**int->float
may be relatively small (though extremely annoying for those that it
happens to, and it would definitely be good to have statistics). I
mean, Numpy silently transitioned to int32+uint64->float64 not so long
ago which broke my code, but the world didn’t end.
If the primary argument against int**int->float seems to be the
difficulty of managing the transition, with int**int->Error being the
seen as the required yet *very* painful intermediate step for the
large fraction of the int**int users who didn’t care if it was int or
float (e.g. the output is likely to be cast to float in the next step
anyway), and fail loudly for those users who need int**int->int, then
if you are prepared to risk a less conservative transition (i.e. we
think that latter group is small enough) you could skip the error on
users and just throw a warning for a couple of releases, along the
WARNING int**int -> int is going to be deprecated in favour of
int**int->float in Numpy 1.16. To avoid seeing this message, either
use “from numpy import __future_float_power__” or explicitly set the
type of one of your inputs to float, or use the new ipower(x,y)
function for integer powers.