BUG: Inconsistent `RuntimeWarning`s "invalid value encountered in reduce"

[bersbersbers]

Describe the issue:

I get warnings when summing Inf and -Inf (which is NaN), but not when summing 5 and NaN (which is NaN) nor when summing Inf and Inf.

I would prefer not seeing a warning in any of these cases.

Reproduce the code example:

# Warning:
python -c "import numpy as np; print(np.sum([np.Inf, -np.Inf]))"

# No warning:
python -c "import numpy as np; print(np.sum([5, np.nan]))"   
python -c "import numpy as np; print(np.sum([np.Inf, np.Inf]))"

Error message:

site-packages\numpy\core\fromnumeric.py:86: RuntimeWarning: invalid value encountered in reduce
  return ufunc.reduce(obj, axis, dtype, out, **passkwargs)

NumPy/Python version information:

1.23.4 3.10.8 (tags/v3.10.8:aaaf517, Oct 11 2022, 16:50:30) [MSC v.1933 64 bit (AMD64)]

Context for the issue:

See also https://stackoverflow.com/q/74552683/880783

[bersbersbers]

I have been made aware that

python -c "import numpy as np; np.subtract(np.inf, np.inf)"  

raises a warning ("RuntimeWarning: invalid value encountered in subtract") while

python -c "import numpy as np; np.inf - np.inf"

does not.

So this issue has nothing to do with reduce, specifically.

---

In addition, I have come across a rather obscure example where two identically-looking arrays behave differently:

The difference is visible only in the underlying bytes, and it allowed me to create these small examples:

import numpy as np

y = np.frombuffer(b'\x00~', dtype=np.float16)
print(y)
y - 0  # emits no warning

x = np.frombuffer(b'\x00}', dtype=np.float16)
print(x)
x - 0  # emits warning

Similarly,

import numpy as np

y = np.frombuffer(b'\x00\x00\xc0\x7f', dtype=np.float32)
print(y)
y - 0  # emits no warning

x = np.frombuffer(b'\x00\x00\xa0\x7f', dtype=np.float32)
print(x)
x - 0  # emits warning

and

import numpy as np

y = np.frombuffer(b'\x00\x00\x00\x00\x00\x00\xf8\x7f', dtype=np.float64)
print(y)
y - 0  # emits no warning

x = np.frombuffer(b'\x00\x00\x00\x00\x00\x00\xf4\x7f', dtype=np.float64)
print(x)
x - 0  # emits warning

So in all examples, while both values are NaN, only the latter emits the warning. Checking the float32 values, 0x7fc00000 and 0x7fa00000, in https://www.h-schmidt.net/FloatConverter/IEEE754.html, both seem to be proper NaN values. Wikipedia confirms that 32-bit values of the form s111 1111 1xxx xxxx xxxx xxxx xxxx xxxx (with s ignored) are NaN values if not all x are 0. However, it mentions the difference between quiet and signaling NaN, and the difference between x and y above seems to be exactly that difference (0x7fc00000 having the first, "quiet" bit set to 1, 0x7fa00000 has it set to 0).

---

So this might be one explanation. However, applying this analysis to the original examples, we see that both variants generate the same type of NaN, but only the latter emits a warning:

import numpy as np

a = np.array(np.inf - np.inf)
a.tobytes()

b = np.subtract(np.inf, np.inf)
b.tobytes()

As float32, we see it is the quiet NaN:

import numpy as np

a = np.array(np.inf - np.inf, dtype=np.float32)
a.tobytes()

b = np.subtract(np.inf, np.inf, dtype=np.float32)
b.tobytes()

So that does not explain why a warning is emitted in this example.

Edit: and while this analysis was an interesting learning for myself, it seems that floating-point operations should never generate a signaling NaN anyway, compare https://stackoverflow.com/a/55648118/880783. If there is a good reason why np.subtract(np.inf, np.inf) emits a warning, it must be a different one.

[seberg]

Everything you observe is exactly what IEEE defines. Signaling NaNs would even warn for 5. + sNaN. So you are digging too deep there. (Practically?) nobody uses signalling NaNs, I wouldn't even bother to ensure they work "correctly" in NumPy, most compilers probably don't either.

Use with np.errstate(...): (as the best API for most things) and check the np.seterr docs.