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

Ilhan Polat ilhanpolat at gmail.com
Wed Feb 26 17:28:39 EST 2020


Does this mean that np.round(np.float32(5)) return a 64 bit upcasted int?

That would be really awkward for many reasons pandas frame size being
bloated just by rounding for an example. Or numpy array size growing for no
apparent reason

I am not really sure if I understand why LSP should hold in this case to be
honest. Rounding is an operation specific for the number instance and not
for the generic class.




On Wed, Feb 26, 2020, 21:38 Robert Kern <robert.kern at gmail.com> wrote:

> On Wed, Feb 26, 2020 at 3:19 PM Hameer Abbasi <einstein.edison at gmail.com>
> wrote:
>
>>
>> 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
>>
>> The only reason that float.__round__() was allowed to change to returning
> ints was because ints became unbounded. If we also change to returning an
> integer type, it should be a Python int.
>
> --
> Robert Kern
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200226/be82f13c/attachment-0003.html>


More information about the NumPy-Discussion mailing list