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