[Numpy-discussion] Output type of round is inconsistent with python built-in

[Hameer Abbasi]

Hello,

Currently, the built-in Python round (which is different from np.round) when called on a np.float64 returns a np.float64, due to its __round__ method. A congruous statement is true for np.float32. However, since Python 3, the default behavior of round is to return a Python int when it operates on a Python float. This is a mismatch according to the Liskov Substitution Principle<https://en.wikipedia.org/wiki/Liskov_substitution_principle>, as both these types subclass Python’s float. This has been brought up in gh-15297<https://github.com/numpy/numpy/issues/15297>. Here is the problem summed up in code:

>>> type(round(np.float64(5)))
<class 'numpy.float64'>
>>> type(round(np.float32(5)))
<class 'numpy.float32'>
>>> type(round(float(5)))
<class 'int'>

This problem manifests itself most prominently when trying to index into collections:

>>> np.arange(6)[round(float(5))]
5
>>> np.arange(6)[round(np.float64(5))]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: only integers, slices (`:`), ellipsis (`...`), numpy.newaxis (`None`) and integer or boolean arrays are valid indices

There still remains the question, do we return Python ints or np.int64s?

  *   Python ints have the advantage of not overflowing.
  *   If we decide to add __round__ to arrays in the future, Python ints may become inconsistent with our design, as such a method will return an int64 array.

This was issue was discussed in the weekly triage meeting today, and the following plan of action was proposed:

  *   change scalar floats to return integers for __round__ (which integer type was not discussed, I propose np.int64)
  *   not change anything else: not 0d arrays and not other numpy functionality
Does anyone have any thoughts on the proposal?
Best regards,
Hameer Abbasi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200226/5f9c7fb2/attachment.html>