On Tue, 11 Oct 2016, Peter Creasey 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 lines of:
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.
Sorry for coming too late to the discussion and after PR "addressing" the issue by issuing an error was merged [1]. I got burnt by new behavior while trying to build fresh pandas release on Debian (we are freezing for release way too soon ;) ) -- some pandas tests failed since they rely on previous non-erroring behavior and we got numpy 1.12.0~b1 which included [1] in unstable/testing (candidate release) now. I quickly glanced over the discussion but I guess I have missed actual description of the problem being fixed here... what was it?? previous behavior, int**int->int made sense to me as it seemed to be consistent with casting Python's pow result to int, somewhat fulfilling desired promise for in-place operations and being inline with built-in pow results as far as I see it (up to casting). Current handling and error IMHO is going against rudimentary algebra, where numbers can be brought to negative power (integer or not). [1] https://github.com/numpy/numpy/pull/8231 -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik