What platform, numpy and Python versions are you using? On my system (Mac OSX), with Python 3.7 and 3.8, and with numpy master branch and 1.17.4, I don't get a warning.

Aha, very interesting! I'm on Linux,

$ python3 --version
Python 3.7.5

$ python3 -c "import numpy; print(numpy.__version__)"
1.18.0.dev0+637d403

(master).

I see it as well on linux, the issue is that the C comparison with 0 sets the flag. In principle the function could simply not check the floating point flags, but not sure how well our machinery is equipped for that currently (you can clear it at the end of each loop, adds a bit of overhead though). alternatively check for NaN. I suppose either of those solution may have a noticeable speed loss.

I don;t see the warning using gcc 7.4 on ubuntu 18.04, with python 3.6.7 and numpy HEAD.

We had a short discussion around maximum starting with this comment about when we should propagate NAN and when we should warn, with the feeling that if a function propagates NAN it should not warn. Speed considerations should be secondary to correct, consistent behaviour. If that is the general consensus, we should

• document this policy ("propagate" is mentioned for some of the ufuncs, whether warnings are emitted is not. Ufuncs like sqrt do not mention NAN handling at all)
• create a test that will try all the ufuncs, and enforce the policy

I would hazard a guess that np.sign is not the only ufunc that on some platforms and compilers emits a warning.

The pattern used in gh-12236 could point the way to a fix here, note that it was tricky to get this to work for all compilers, intrinsics, and optimization levels.

The current code is in1 > 0 ? 1 : (in1 < 0 ? -1 : (in1 == 0 ? 0 : in1)); maybe using npy_isnan doesn't really matter anyway. Although I find it curious that some comparison set the flag and others do not.
I get the warning both with the numpy shipped with debian (testing) as well as with master (gcc 9.2). Comparisons also give the warning, but they do not propagate NaN, so its probably right.

Had to add a filter for this in astropy (https://github.com/astropy/astropy/pull/9672/files#diff-4fdade973786257690f0716b79a23e94R714), since we now fail tests on warnings. Would be definitely be nice if this didn't warn but just returned nan.

Yeah, I think we should just go with the quick fix and clear the flag in the ufunc loop probably. We already have a bunch of functions that do that.

This also emits a warning, since it is a non-standard NAN

a = np.packbits([0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
    0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1])
b = a.view(np.float64)
np.isnan(b)
# array([True])
b == np.inf
# RuntimeWarning: invalid value encountered in equal

xref gh-15189

Closed by gh-15230.