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

[Ilhan Polat]

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.

Maybe not a big problem but can have significant impact.

On Thu, Feb 27, 2020, 05:12 Robert Kern <robert.kern at gmail.com> wrote:

> Your example used np.round(), not the builtin round(). np.round() is not
> changing. If you want the dtype of the output to be the dtype of the input,
> you can certainly keep using np.round() (or its canonical spelling,
> np.around()).
>
> On Thu, Feb 27, 2020, 12:05 AM Ilhan Polat <ilhanpolat at gmail.com> wrote:
>
>> It's not about what I want but this changes the output of round. In my
>> example I didn't use any arrays but a scalar type which looks like will
>> upcasted.
>>
>> On Wed, Feb 26, 2020, 23:04 Robert Kern <robert.kern at gmail.com> wrote:
>>
>>> On Wed, Feb 26, 2020 at 5:41 PM <josef.pktd at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 26, 2020 at 5:30 PM Ilhan Polat <ilhanpolat at gmail.com>
>>>> wrote:
>>>>
>>>>> 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
>>>>>>>
>>>>>>>
>>>> I think making numerical behavior different between arrays and numpy
>>>> scalars with the same dtype, will create many happy debugging hours.
>>>>
>>>
>>> round(some_ndarray) isn't implemented, so there is no difference to
>>> worry about.
>>>
>>> If you want the float->float rounding, use np.around(). That function
>>> should continue to behave like it currently does for both arrays and
>>> scalars.
>>>
>>> --
>>> Robert Kern
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> 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/20200227/d3a319b5/attachment.html>