scipy/linalg/tests/test_decomp.py::TestSchur::test_sort test failure
See original GitHub issuescipy/linalg/tests/test_decomp.py::TestSchur::test_sort
test fails in 1.7.1 (IIRC 1.7.0 too).
Error message:
_________________________________________________________ TestSchur.test_sort _________________________________________________________
scipy/linalg/tests/test_decomp.py:1918: in test_sort
assert_array_almost_equal([[0.1134, 0.5436, 0.8316, 0.],
E AssertionError:
E Arrays are not almost equal to 3 decimals
E
E Mismatched elements: 8 / 16 (50%)
E Max absolute difference: 1.64897635
E Max relative difference: 2.00019569
E x: array([[ 0.113, 0.544, 0.832, 0. ],
E [-0.113, -0.825, 0.554, 0. ],
E [-0.821, 0.131, 0.026, -0.555],
E [-0.547, 0.087, 0.018, 0.832]])
E y: array([[-1.134e-01, -5.436e-01, 8.316e-01, -5.470e-15],
E [ 1.134e-01, 8.245e-01, 5.544e-01, -4.318e-15],
E [ 8.213e-01, -1.308e-01, 2.650e-02, -5.547e-01],
E [ 5.475e-01, -8.718e-02, 1.767e-02, 8.321e-01]])
a = [[4.0, 3.0, 1.0, -1.0], [-4.5, -3.5, -1.0, 1.0], [9.0, 6.0, -4.0, 4.5], [6.0, 4.0, -3.0, 3.5]]
s = array([[-1.41421356, 0.14557215, 11.58158585, 7.71743518],
[ 0. , -0.5 , -9.44719662, 0.7184405... [ 0. , 0. , 1.41421356, -0.14557215],
[ 0. , 0. , 0. , 0.5 ]])
sdim = 2
self = <scipy.linalg.tests.test_decomp.TestSchur object at 0x7f88fcebe9d0>
u = array([[-1.13395338e-01, -5.43632173e-01, 8.31628257e-01,
-5.47030881e-15],
[ 1.13395338e-01, 8.24476...33e-02,
-5.54700196e-01],
[ 5.47521126e-01, -8.71829392e-02, 1.76652155e-02,
8.32050294e-01]])
Scipy/Numpy/Python version information:
$ python3.8 -c 'import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)'
1.7.1 1.21.1 sys.version_info(major=3, minor=8, micro=11, releaselevel='final', serial=0)
Issue Analytics
- State:
- Created 2 years ago
- Comments:16 (8 by maintainers)
Top Results From Across the Web
How to handle test failures — pytest documentation
This will invoke the Python debugger on every failure (or KeyboardInterrupt). Often you might only want to do this for the first failing...
Read more >long running py.test stop at first failure - Stack Overflow
I am using pytest , and the test execution is supposed to run until it encounters an exception. If ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
It looks like the problem is actually the test. The Schur decomposition is not unique. As @ilayn pointed out in a previous comment, in the failing test, the signs of the first two columns of the unitary factor are flipped. One can see that some of the signs in the triangular factor are also flipped, and it turns out that these sign changes are consistent with the sign changes in the unitary factor.
Here’s the test calculation when it passes:
E
is a reflection of the first two columns when it multiplies a matrix on the right:Compute another Schur decomposition from
u
ands
;u2
ands2
look like the solutions computed in the failing test:Verify that this is a correct Schur decomposition:
Check that
u2
is unitary:So we have to fix the test.
This has started to fail in the macOS Meson CI job consistently now (see for example https://github.com/scipy/scipy/runs/7772683544?check_suite_focus=true), and I bet that it’s due to OpenBLAS
0.3.21
becoming available on conda-forge (that CI job is the only one using conda-forge, and it does pull in0.3.21
).