FWIW in pandas we post-process floordiv (and divmod) ops to get the "Expected Result" behavior from the OP.
On Fri, May 8, 2020 at 11:56 AM Anirudh Subramanian <anirudh2...@gmail.com> wrote: > Hi all, > > There has been a discussion about divmod (1.0, 0.0) bug here : > https://github.com/numpy/numpy/issues/14900 and > https://github.com/numpy/numpy/pull/16161 . > > *SUMMARY* > > Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan, > nan). This is not consistent with IEEE 754 > <https://en.wikipedia.org/wiki/IEEE_754> standard which says that 1.0/0.0 > divisions should return inf and raise dividebyzero error. Although this may > not apply to divmod, it should apply to floor_divide and mod. > I have summarized in the table below, summarizing current state and > expected state. > > Operator Warning message Expected warning Result Expected Result > np.divmod Invalid error invalid and dividebyzero ?? nan, nan inf, nan > np.fmod(1.0, 0.0) Invalid error Invalid nan nan > np.floor_divide(1.0, 0.0) Invalid error Dividebyzero nan inf > np.remainder(1.0, 0.0) Invalid error Invalid nan nan > > > For remainder and fmod above, according to the standard, it is supposed to > raise invalid error. We need to change the code to also raise dividebyzero > error for floor_divide. > > The question is what to do for np.divmod (since this is not defined by > standard). My opinion is in this case we need to set both dividebyzero and > invalid error flags since its a combination of these two operations. > > *USER IMPACT* > > This is going to cause a breaking change/silent incorrect results to > atleast some users who are either doing one or two of the following: > 1. expecting nans from their output and check isnan but not isinf in their > code and accordingly do further computations. > 2. who currently call raise only on invalid and not dividebyzero errors > for any of the above listed operations. > > Considering this we can try one of the two things: > 1. Create a futurewarning for every divmod(1.0, 0.0) path. This may be > very noisy and I cannot think of an action for a user to take to suppress > this. > 2. Since bug fixes are exempt from backwards compatibility policy > <https://numpy.org/neps/nep-0023-backwards-compatibility.html> just > notify in the release notes, maybe after a couple of releases. (More > Impactful) > > *OTHER ISSUES?* > > Depending on the compiler, and if it implements annex F of the C standard, > it may not support 1.0/0.0 operation and may crash. Also this is the case > for true_divide also, so we wont be breaking more users than we currently > are. > > Would like to hear your thoughts about this! > > Anirudh > > _______________________________________________ > 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