On Thu, Sep 9, 2021 at 7:11 PM Sebastian Berg <sebast...@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 < > > kshitijkalambar...@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@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 > > _______________________________________________ > 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
