TST: linalg: add a regression test for a gen eig problem

[ev-br]

So far nobody managed to reproduce it, and gh-11577 appears to have been fixed upstream. Thus add a test to make sure we catch it if it shows up again.

closes gh-11577

[tylerjereddy]

Any reason not to use the built-in testing assertion? This works for me locally at least:

--- a/scipy/linalg/tests/test_decomp.py
+++ b/scipy/linalg/tests/test_decomp.py
@@ -369,11 +369,7 @@ class TestEig:
         # The problem is ill-conditioned, and two other eigenvalues
         # depend on ATLAS/OpenBLAS version, compiler version etc
         # see gh-11577 for discussion
-        with np.testing.suppress_warnings() as sup:
-            # isclose chokes on inf/nan values
-            sup.filter(RuntimeWarning, "invalid value encountered in multiply")
-            assert np.isclose(D, 4.0, atol=1e-14).any()
-            assert np.isclose(D, 8.0, atol=1e-14).any()
+        assert_allclose(D[:2], [4.0, 8.0], atol=1e-14)

I think that may give slicker error messages if it ever fails alongside graceful non-finite handling.

Apart from that, looks solid.

[ev-br]

My original reasoning was 1) I don't remember if assert_allclose is gracefully handling nans and infs, and 2) I don't know if the order is guaranteed, whether two "other" values are always in the 3rd and 4th places.

That said, let's declare both concerns to be FUD until proven real. So the PR is updated with your patch, in a separate commit to simplify reverting if it ever comes to that :-).

[ev-br]

Okay, here it is: locally the order is [8.0, 4.0, rest] and CI failures are because it is [4.0, 8.0, rest]. Typically I'd expect that I'd need to sort the eigenvalues before comparing them because the ordering from LAPACK is not guaranteed. Here sorting is not an option because of "rest". OK to revert to the previous manual version?

[tylerjereddy]

locally the order is [8.0, 4.0, rest]

Ok, so even your local order doesn't match my local order from above.

That's annoying. I see eigvals explicitly documents w as:

The eigenvalues, each repeated according to its multiplicity but not in any specific order.

While the function you use here (eig) doesn't actually say that in the docs. Reverting makes sense then I guess. There are other blemishes in the API too, like the left eigenvector not being normalized while the right one is normalized (a fact that wasn't even documented until recently).

[ev-br]

There are other blemishes in the API too

ISTM the root is that eig tries to be too helpful in too many ways. Cramming two rather different things into one function (regular and generalized eigenvalue problem, for starters). Then it tries to go beyond what LAPACK actually offers (sorting? normalization?). Water under the bridge now anyway.

[tylerjereddy]

self-merging when CI passes after the revision makes to me I think

[tylerjereddy]

I double checked just now that the CI failure can't possibly be related--our latest main against latest NumPy main as of a few minutes ago passes full test suite, and you only added a test without changing source of course.

I think we're just seeing some mismatch on nightlies or not having Sebastian's patch in the base branch or whatever, so in it goes, thanks.