Repository navigation
RuntimeWarning: divide by zero encountered in reciprocal for np.ones(3) ** -1 #18555
Description
Reproducing code example:
import numpy as np
with np.errstate(invalid="raise"):
np.ones(3) ** -1 raises:
<ipython-input-43-02fd0a095546>:2: RuntimeWarning: divide by zero encountered in reciprocal
np.ones(3) ** -1but the result of the evaluation is still correct: array([1., 1., 1.])...
I also tried 1 / np.ones(3), np.ones(2) ** -1, np.ones(4) ** -1 which do not raise the warning.
I get it for any numpy array of 3 items with dtype np.float32 or np.float64 but not np.complex64 for instance.
NumPy/Python version information:
I got the problem with:
1.20.1 3.9.2 | packaged by conda-forge | (default, Feb 21 2021, 05:00:30)
[Clang 11.0.1 ]
on macos/arm64.
I cannot get it from a linux/aarch64 docker environment running on the same machine numpy installed from PyPI.org with version:
1.20.1 3.9.1 (default, Dec 12 2020, 08:46:48)
[GCC 8.3.0]
I cannot get it from a linux/aarch64 docker environment running on the same machine numpy installed from conda-forge with version:
1.20.1 3.9.2 | packaged by conda-forge | (default, Feb 21 2021, 05:02:26)
[GCC 9.3.0]
So maybe this is a bug related to clang or macos/arm64? Could someone with an intel mac try to reproduce it, preferably using the numpy from conda-forge?
Activity
seberg commentedon Mar 5, 2021
@ogrisel I think we might be running into #18005, i.e. clang has the terrible default of not using
-ffp-exception-behavior=strict! There are already a few places in the code working around that I think. Try setting the flag if that fixes it. We really should force that flag, but I am not well versed with distutils or clang so was never sure where to add it when I looked at it once.ogrisel commentedon Mar 5, 2021
I built numpy master with:
and I still get the
RuntimeWarning.Here is the build log:
https://gist.github.com/ogrisel/d104c8cf1b1c13202c204f3cc0004e38
seberg commentedon Mar 5, 2021
Hmm, thought it was worth a shot, since apparently without the flag clang feels free to do optimizations that can make the floating point exceptions all wrong.
Still seems likely to be a bug with clang or glibc on macos/arm64, but I am not certain.
ogrisel commentedon Mar 7, 2021
Not a big problem because it's just a warning and the result is correct. Still it's annoying in for libraries that checks that that warnings are not raised in a given context.
isuruf commentedon Mar 8, 2021
The fix should be the same as in #18571 for
reciprocalerykoff commentedon Mar 8, 2021
Interesting. Is this also a problem with the latest Xcode compiler or just the conda compiler (which is a version behind). I believe the problem in #17712 was not present with the latest Xcode compiler (clang 12) which presumably fixed that look-ahead exception bug.
isuruf commentedon Mar 8, 2021
Yes.
Not really. conda compiler is actually ahead. The versioning schemes are different though.
isuruf commentedon Apr 28, 2021
This is not the same issue as #18571. It turns out that this is due to branch prediction going wrong in the for loop and floating point exceptions being raised for the wrong branch.
np.ones(120)[:120] ** -1gives the warning, butnp.ones(120)[:119] ** -1doesn't.ogrisel commentedon Apr 28, 2021
Shall we report the issue upstream to LLVM (I assume) and just mark the failing
TestUfuncGenericLoops::test_unary_PyUFunc_O_O_method_full[reciprocal]test (see #18143 (comment)) as XFAIL?isuruf commentedon Apr 29, 2021
I don't have a small testcase to report this issue upstream. Besides I'm not even sure if it's a compiler issue or a hardware bug.
charris commentedon May 6, 2021
Going to push this off to 1.22.0 for tracking. It seems the problem is not directly connected to NumPy.
FIX ignore spurious RuntimeWarning in test on macOS M1 machines
Resolve divide by zero in reciprocal numpy#18555
Enhancement on top of workaround for clang bug in reciprocal
BUG: Resolve Divide by Zero on Apple silicon + test failures (#19926)
BUG: Resolve Divide by Zero on Apple silicon + test failures (numpy#1…
BUG: Resolve Divide by Zero on Apple silicon + test failures (numpy#1…