[Numpy-discussion] np.trunc is inconsistent with array-api

[Aaron Meurer]

On Thu, Sep 9, 2021 at 7:11 PM Sebastian Berg
<sebastian at sipsolutions.net> wrote:
>
> On Sun, 2021-09-05 at 21:08 +0200, Ralf Gommers wrote:
> > On Sat, Sep 4, 2021 at 10:02 AM Kshitij Kalambarkar <
> > kshitijkalambarkar at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > np.trunc returns floating dtype output even for integral dtype
> > > input. As
> > > per array-api, it should preserve the input dtype.
> > >
> >
> > Just a note that it's not compatibility with the array API standard
> > that's
> > the main driver for the change here (that would be handled in
> > `numpy.array_api.trunc`, not `numpy.trunc`). But it's just unwanted
> > behavior, so an improvement to `numpy.trunc` is also desirable.
> >
> >
> > > Note: This is also true for np.rint, np.fix, np.ceil, np.floor
> > >
> > > Reference: https://github.com/numpy/numpy/issues/19464
> > >
> > > Possible Fix:
> > > 1. We update the behaviour directly with an update to release note.
> > > 2. We add a FutureWarning and update the behaviour in a future
> > > release.
> > >
> >
> > I'm fine with (1), because (a) it can be considered a bug fix, (b)
> > it's
> > unlikely to break anything, and (c) a FutureWarning is not too
> > helpful
> > because there's no way to update existing code to be forward-proof
> > and
> > remove the warning.
>
> One work-around might be to pass `dtype=arr.dtype` probably, but that
> would fail on current NumPy.  So the only choice would probably be
> explicitly not calling `trunc`.
>
> So, I agree, I lean towards moving forward here.  (Unless anyone has
> e.g. an example of code that would break?)
>
>
> There is a tiny possibility of catastrophic failure (silent wrong
> results).  But my best guess is that the vast majority of code probably
> will not notice.
> E.g. one pattern that is probably extremely common is to cast to
> integer right after the call to `trunc`.

If that's true, then this may actually fix some bugs. If some code
does trunc(x).astype(int) and x could be float or int, then the result
will be wrong if x is int64 with values larger than ~2**54, which
cannot fit exactly into float64, e.g.,

>>> np.trunc(11962686510203121).astype(int)
11962686510203120

I'm not sure I understand how changing this could lead to new wrong results.

Aaron Meurer

>
> Cheers,
>
> Sebastian
>
>
> >
> > Cheers,
> > Ralf
> >
> >
> > > This email is to gauge the preference for the fix.
> > >
> > > Thank You!
> > >
> > > Regards,
> > > Kshiteej K
> > >
> > >
> > >
> > > _______________________________________________
> > > 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