exp(NINF) returns underflow error after version 1.20
We have an interesting situation where a test suite that checks the value of e^-inf is behaving differently depending on Numpy version. The minimal test I'm using is: #!/usr/bin/env python3 import numpy as np np.seterr(under='raise') print(np.exp(np.NINF)) With numpy version 1.19.5 and 1.20.3 we consistently get "0.0" as the result. Later versions- 1.21 and 1.22- raise an underflow error: Traceback (most recent call last): File "./under.py", line 4, in <module> print(np.exp(np.NINF)) FloatingPointError: underflow encountered in exp A further confounding factor is that on our slightly older processors we don't get this underflow, instead returning 0. The Python and GCC toolchains is the same thanks to environment modules and the OS and patches are the same on both generations, but the older processors (Intel Xeon E5-2667) return 0 and the newer (Intel Xeon Gold 6254) return underflow with the newer numpy versions. I think my primary question is what is the expected result for this function? I sort of expect this to be defined as zero but I've been unable to find documentation of this fact. Underflow does sort of make sense in this situation as well. However, the inconsistency is concerning and I'm uncertain if it would affect results from other calculations. Thanks much - Michael
On Mon, 2022-01-24 at 19:37 +0000, Michael Gutteridge wrote:
We have an interesting situation where a test suite that checks the value of e^-inf is behaving differently depending on Numpy version. The minimal test I'm using is:
#!/usr/bin/env python3 import numpy as np np.seterr(under='raise') print(np.exp(np.NINF))
With numpy version 1.19.5 and 1.20.3 we consistently get "0.0" as the result. Later versions- 1.21 and 1.22- raise an underflow error:
Traceback (most recent call last): File "./under.py", line 4, in <module> print(np.exp(np.NINF)) FloatingPointError: underflow encountered in exp
A further confounding factor is that on our slightly older processors we don't get this underflow, instead returning 0. The Python and GCC toolchains is the same thanks to environment modules and the OS and patches are the same on both generations, but the older processors (Intel Xeon E5-2667) return 0 and the newer (Intel Xeon Gold 6254) return underflow with the newer numpy versions.
I think my primary question is what is the expected result for this function? I sort of expect this to be defined as zero but I've been unable to find documentation of this fact. Underflow does sort of make sense in this situation as well. However, the inconsistency is concerning and I'm uncertain if it would affect results from other calculations.
Thanks for the report. Could you open an issue about this (And maybe ping @r-devulap on it)? Underflow warnings are ignored by default, so this would sneak under the radar easily. Just to be clear: If this is not an easy fix, I am not sure we should bother. Getting FPEs (floating point errors) right 100% is tricky, also because compilers do get them wrong often enough (it improved, but older compilers or math libraries can be problematic, e.g. older clang versions get things wrong a lot). That said, I do expect you are right and no warning should be given here and that there is a problem in the SIMD version (acceleration for more advanced CPU instruction sets). But the question is how deep that issue is :). Cheers, Sebastian
Thanks much
- Michael _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
participants (2)
-
Michael Gutteridge -
Sebastian Berg