[Numpy-discussion] round(numpy.float64(0.0)) is a numpy.float64

[Robert Kern]

On Mon, Mar 26, 2018 at 6:28 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
> On Mon, Mar 26, 2018 at 6:24 PM, Nathaniel Smith <njs at pobox.com> wrote:
> > Even knowing that, it's still confusing that round(np.float64(0.0))
> > isn't the same as round(0.0). The reason is a Python 2 / Python 3
> > thing: in Python 2, round returns a float, while on Python 3, it
> > returns an integer – but numpy still uses the python 2 behavior
> > everywhere.
> >
> > I'm not sure if it's possible or worthwhile to change this. If we'd
> > changed it when we first added python 3 support then it would have
> > been easy (and obviously a good idea), but at this point it might be
> > tricky?
>
> Oh right, and I forgot: part of the reason it's tricky is that it
> really would have to return a Python 'int', *not* any of numpy's
> integer types, because floats have a much larger range than numpy
> integers, e.g.:

I don't think that's the tricky part. We don't have to change anything but
our implementation of Python 3's __round__() special method for np.generic
scalar types, which would be straightforward. The only issue, besides
backwards compatibility, is that it would introduce a new inconsistency
between scalars and arrays (which can't use the Python ints). However,
that's "paid for" by the increased compatibility with the rest of Python.
For a special method that is used for to interoperate with a Python builtin
function, that's probably the more important consistency to worry about.

As for the backwards compatibility concern, I don't think it would matter
much. Everyone who has written code that expects round(np.float64(...)) to
return a np.float64 is probably already wrapping that with int() anyways.
Anyone who really wants to keep the scalar type of the output same as the
input can use np.around().

--
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180326/8b4a66a7/attachment.html>