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