On Fri, Jun 10, 2016 at 12:42 AM Nathaniel Smith <n...@pobox.com> wrote:
> On Mon, Jun 6, 2016 at 1:17 PM, Charles R Harris > <charlesr.har...@gmail.com> wrote: > > > > > > > > On Mon, Jun 6, 2016 at 2:11 PM, Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> > >> Hi Chuck, > >> > >> I consider either proposal an improvement, but among the two I favour > returning float for `**`, because, like for `/`, it ensures one gets > closest to the (mathematically) true answer in most cases, and makes > duck-typing that much easier -- I'd like to be able to do x** y without > having to worry whether x and y are python scalars or numpy arrays of > certain type. > >> > >> I do agree with Nathaniel that it would be good to check what actually > breaks. Certainly, if anybody is up to making a PR that implements either > suggestion, I'd gladly check whether it breaks anything in astropy. > >> > >> I should add that I have no idea how to assuage the fear that new code > would break with old versions of numpy, but on the other hand, I don't know > its vailidity either, as it seems one either develops larger projects for > multiple versions and tests, or writes more scripty things for whatever the > current versions are. Certainly, by this argument I better not start using > the new `@` operator! > >> > >> I do think the argument that for division it was easier because there > was `//` already available is a red herring: here one can use `np.power(a, > b, dtype=...)` if one really needs to. > > > > > > It looks to me like users want floats, while developers want the easy > path of raising an error. Darn those users, they just make life sooo > difficult... > > I dunno, with my user hat on I'd be incredibly surprised / confused / > annoyed if an innocent-looking expression like > > np.arange(10) ** 2 > > started returning floats... having exact ints is a really nice feature > of Python/numpy as compared to R/Javascript, and while it's true that > int64 can overflow, there are also large powers that can be more > precisely represented as int64 than float. > > -n > > > This is very much my line of thinking as well. Generally when I'm doing operations with integers, I expect integer output, regardless of floor division and overflow. There's a lot to both sides of the argument though. Python's arbitrary precision integers alleviate overflow concerns very nicely, but forcing float output for people who actually want integers is not at all ideal either. Best, Ian Henriksen
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
