BUG: exp(NINF) returns underflow error after version 1.20

[atombaby]

Describe the issue:

We have an interesting situation where a test suite that checks the value of e^-inf is behaving differently depending on Numpy version. 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. We are running Python 3.8.6 built by GCC 10.2.0 and using virtual environments to install these Numpy versions.

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'd posted the issue to the mailing list where it was suggested that we should expect a result of 0 and that this may be an issue in the SIMD version.

Thanks for looking- please let me know if there's any additional information I can provide.

Reproduce the code example:

#!/usr/bin/env python3
import numpy as np
np.seterr(under='raise')
print(np.exp(np.NINF))

Error message:

Traceback (most recent call last):
  File "./under.py", line 4, in <module>
    print(np.exp(np.NINF))
FloatingPointError: underflow encountered in exp

NumPy/Python version information:

Numpy: 1.21.4
Python: 3.8.6 (default, Dec 16 2020, 13:45:25) [GCC 10.2.0]

[r-devulap]

@seberg taking a look.

[seberg]

Just had a brief search, and it says here

Whether an operation raises this exception is implementation-defined: there are no operations required to raise this exception, but an implementation may choose to do so.

So, while the underflow warning here seems incorrect to me, that bolsters the argument that we should likely not bother too much about underflows if this is not an easy fix.

[r-devulap]

The fix is simple (or at least I think it is), but its triggering a lot of unrelated test failures :/ For example, I get an FloatingPointError: invalid value encountered in the 128 bit exp function after fixing the 64-bit exp function, which seems odd.

[seberg]

That seems extremely strange? The longdouble version should be using the glibc implementation to begin with? We had weird stuff like that because of some FP stack overflow, but I did not quite follow that problem: #20410

[r-devulap]

yup, the test failures look pretty similar and unrelated. But at least it gives me a direction to look into.

[r-devulap]

r-devulap@76f8584 fixes this bug which is a simple fix but triggers a bug in gcc (even gcc-10) which results in a ton of test failures (see #20356 (comment)). Still thinking of a work around for the bug.

[r-devulap]

PR #20991 fixes this problem.

[atombaby]

Can confirm:

(3.8.6-GCCcore-10.2.0)[~/Work/numpy]: ./under-longer.py
Numpy acquired from:  numpy/gizmok/Python/3.8.6-GCCcore-10.2.0/lib/python3.8/site-packages/numpy/__init__.py
Numpy version: 0.3.0+28244.g87fb01c65
np.exp(np.NINF):  0.0
Traceback (most recent call last):
  File "./under-longer.py", line 9, in <module>
    print("np.exp(large negative number:", np.exp(-100000000000000000000000000000000000000.0))
FloatingPointError: underflow encountered in exp

Thanks!

• Michael

[r-devulap]

PR #20991 had to be modified. @atombaby Could you double check if the patch fixes this problem?

[atombaby]

This patch seems to work fine too:

(3.8.6-GCCcore-10.2.0)[~/Work/numpy]: ./under-longer.py 
Numpy acquired from:  numpy/gizmok/Python/3.8.6-GCCcore-10.2.0/lib/python3.8/site-packages/numpy/__init__.py
Numpy version: 0.3.0+28250.gb3eed1459
np.exp(np.NINF):  0.0
Traceback (most recent call last):
  File "./under-longer.py", line 9, in <module>
    print("np.exp(large negative number:", np.exp(-100000000000000000000000000000000000000.0))
FloatingPointError: underflow encountered in exp