ENH: Add floating point error checking to (almost) all casts

[seberg]

This, unfortunately larger, PR tries to add floating point error checking to all places where this is necessary. Unfortunately, there are a few places, the most complicated one being the advanced indexing (simply because there are many branches – note that only assignments are truly relevant).

Doing this also required threading it into the NpyIter, the way this is used from elsewhere is a cludge (due to being non-public API).

There are a few smaller problems (most of which we can hopefully ignore):

• I did not fix ufunc.at, but that has its own problems anyway, so I am not too concerned about it.
• The masked array code (due to the fill value) runs into these warnings now. It is easy enough to ignore it/silence it in the tests, but it is a bit unclear what should happen.
• Probably something else I am missing

There is still some cleanup and maybe simplification necessary, so marking as draft. But this will close a few open issues, and it ensures the warning for np.float32(2e200).
So, I think it is both a pretty worthwhile thing, and is one of those warnings that I would like to have available when we/if we switch to "weak Python scalar" promotion (remove value based casting).

[seberg]

Hmm, looking at the failures:

1. Travis failure seems like a gcc bug on power64le (I think I can reproduce it in godbolt). It generates an xvcmpgedp instruction. The "ge" in there stands for greater-equal. I could not find it, but a "ge" instruction should set the "invalid" warning flag. Replacing the code with != seems to fix it, we may want to do that platform specific. != doesn't seem good enough, this needs some other fix to get proper unordered/quiet comparisons.
2. The PyPy issue seems OK, it looks like a variant of
   BUG: ufuncs that call into Python do not ignore FPEs e.g. for inf - inf #21416 and should probably just be ignored. (I did not look into whether there is also something slightly not-ideal going on in PyPy.)
3. The last failure puzzles me right now. It seems like a serious issue somewhere since the tuple seems to be converted to an empty array, which is complete nonsense. valgrind did not point to anything strange close to these tests though. So for now, I am unsure what to look for. A reference counting issue, with needs_api being set incorrectly. A bit crazy that it did not crash far more things (although refcount checker would have shouted...).

EDIT: OK, So about 3, valgrind actually does point to an incorrectly free'd tuple (or a double free even), which would add up... Unfortunately, it only shows at interpreter shutdonw.

[seberg]

This should be ready for review now. I think it maybe should have a release not (so tagging). There are still one or two error paths that I will try to cover in tests, but overall I think I got it.

There are some tricky parts here. The first five commits may be good to go through on their own. But overall I will be happy to look at the changes together. The by far worst part I think is the advanced indexing...

EDIT: Hmmm, surprising the test fails only on windows 32bits, but seems that this may not be a fluke but a real refcounting (or cleanup timing/race condition?) issue somewhere. (Shouldn't matter too much for a first review though.)

[mattip]

The code itself is a lot of changes to pass the resultant error state around and looks fine. I think it would be worthwhile to put this in now. Do you know if it breaks any scipy/astropy tests?

[seberg]

Thanks for the review and slashing down the release note. I would like a note somewhere that float to int casts may return undefined values, but its not really right in this note (it is unchanged anyway).

I have not tested downstream test-suites (I may look into that tomorrow or so). OTOH, I don't expect larger problems, and they would be fixable with np.errstate(invalid="ignore") in general. The one annoying point (IMO) is the combination of MaskedArray with float16, that might require fixups (but is also exceedingly rare probably).

[seberg]

Just ran the SciPy 1.8.1 test-suite on this. It has 16 (related) failures, out of which 15 are all in the same test_distances file and seem to fail for the same integer_arr[something] = integer_arr[something] * np.nan assignment. So I suspect they should just deal with integer arrays better (especially since that assignment may be undefined behavior for some integer dtypes!).

EDIT: There are likely a lot more warnings elsewhere which are just not floated for a released version of SciPy!

[mattip]

I am a little hesitant to merge a PR that we know for sure will break SciPy tests. Could you open an issue that refers to this PR?

[seberg]

Not sure if a NumPy or SciPy issue. Happy to followup with either quickly though. I tried checking astropy. Not that the run went perfectly (too old or new pytest version), but it does not look like astropy is affected.

[mattip]

Thanks @seberg