great another object array
np.asarray([round(x_i.item()) for x_i in np.array([1, 2.5, 2e20, 2e200])])
array([1, 2, 200000000000000000000,
199999999999999993946624442502072331894900655091004725296483501900693696871108151068392676809412503736055024831947764816364271468736556969278770082094479755742047182133579963622363626612334257709776896],
dtype=object)
I would rather have numpy consistent with numpy than with python
On Wed, Feb 26, 2020 at 4:38 PM Robert Kern <robert.k...@gmail.com> wrote:
> On Wed, Feb 26, 2020 at 3:19 PM Hameer Abbasi <einstein.edi...@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@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
