Hello, Ilhan,

From: NumPy-Discussion <numpy-discussion-bounces+einstein.edison=gmail.com@python.org> on behalf of Ilhan Polat <ilhanpolat@gmail.com>
Reply to: Discussion of Numerical Python <numpy-discussion@python.org>
Date: Thursday, 27. February 2020 at 08:41
To: Discussion of Numerical Python <numpy-discussion@python.org>
Subject: Re: [Numpy-discussion] Output type of round is inconsistent with python built-in

Oh sorry. That's trigger finger np-dotting.

What i mean is if someone was using the round method on float32 or other small bit datatypes they would have a silent upcasting. 

No they won’t. The only affected types would be scalars, and that too only with the built-in Python round. Arrays don’t define the __round__ method, and so won’t be affected. np.ndarray.round won’t be affected either. Only np_scalar_types.__round__ will be affected, which is what the Python round checks for.

For illustration, in code:

>>> type(round(np_float))

<class 'numpy.float64'>

>>> type(round(np_array_0d))

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: type numpy.ndarray doesn't define __round__ method

>>> type(round(np_array_nd))

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: type numpy.ndarray doesn't define __round__ method

The second and third cases would remain unaffected. Only the first case would return a builtin Python int with what Robert Kern is suggesting and a np.int64 with what I’m suggesting. I do agree with something posted elsewhere on this thread that we should warn on overflow but prefer to be self-consistent and return a np.int64, but it doesn’t matter too much to me. Furthermore, the behavior of np.[a]round and np_arr.round(…) will not change. The only upcasting problem here is if someone does this in a loop, in which case they’re probably using Python objects and don’t care about memory anyway.

Maybe not a big problem but can have significant impact. 

Best regards,

Hameer Abbasi