On Wed, Feb 26, 2020 at 5:41 PM <josef.p...@gmail.com> wrote: > > > On Wed, Feb 26, 2020 at 5:30 PM Ilhan Polat <ilhanpo...@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.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.int64 >>>> s? >>>> >>>> - 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@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
