On Fri, 2021-09-10 at 14:51 -0600, Aaron Meurer wrote: > On Thu, Sep 9, 2021 at 7:11 PM Sebastian Berg > <[email protected]> wrote: > > > > On Sun, 2021-09-05 at 21:08 +0200, Ralf Gommers wrote: > > > On Sat, Sep 4, 2021 at 10:02 AM Kshitij Kalambarkar < > > > [email protected]> 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.,
Sure.
> > > > np.trunc(11962686510203121).astype(int)
> 11962686510203120
>
> I'm not sure I understand how changing this could lead to new wrong
> results.
>
I can't think of a reasonable way either, but e.g. code could run into
integer overflows. It seems all very unlikely, though.
I was thinking a bit in the direction of simple unsafe operations:
res = np.trunc(arr)
res *= 0.5 # will error if res is integer
But most should error and not return bad results...
In any case: I will worry if anyone shows a real-world/likely example
for how it can go wrong. And right now, that seems fairly unlikely.
Cheers,
Sebastian
> 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
> > > > [email protected]
> > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > [email protected]
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
