Hi all,
SUMMARY
Currently divmod(1.0, 0.0) sets the "Invalid error" and returns (nan, nan). This is not consistent with
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 just notify in the release notes, maybe after a couple of releases. (More Impactful)