OpenBLAS 0.3.20 has a bug which makes scipy (current in Gentoo version 1.9.3) output an incorrect result for a generalised eigenvalue problem. Namely, the following is wrong. $ python3 Python 3.10.7 (main, Oct 10 2022, 13:00:40) [GCC 11.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import scipy, numpy >>> A=numpy.array([[ 1., -2.],[ 3., 4.]]) >>> B=numpy.array([[ 0., 7.],[ 2., -3.]]) >>> scipy.linalg.eig(A,B,right=False, left=True, homogeneous_eigvals=False) (array([-2.10757594+0.j, -0.39228096+0.j]), array([[-0.9905316 , -1. ], [ 0.13728493, 0.26423138]])) The correct output should be (array([ 1.82085238+0.j, -0.39228096+0.j]), array([[-0.54007116, -1. ], [-0.84161936, 0.26423138]])) Found while working on https://trac.sagemath.org/ticket/34658
Presumably fixed with openblas-0.3.21?
Indeed, apparently, OpenBLAS 0.3.21 fixes the issue (confirmed indirectly, with an out of system tree build).
openblas-0.3.20 is currently ~arch in any case so skipping it for 0.3.21 should not cause much trouble. If Dima had stuck to arch he would never have seen the issue :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03f1689aa0d72075183bd999192a363994c41195 commit 03f1689aa0d72075183bd999192a363994c41195 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2022-11-12 11:53:59 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2022-11-12 12:05:19 +0000 sci-libs/openblas: add 0.3.21 I had to rebase the loongarch patch, and removed an old workaround for FFLAGS="-fcheck=bounds" in the test suite, but other than that a standard update. Bug: https://bugs.gentoo.org/726474 Closes: https://bugs.gentoo.org/878883 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> sci-libs/openblas/Manifest | 1 + .../openblas/files/openblas-0.3.21-fix-loong.patch | 237 +++++++++++++++++++++ sci-libs/openblas/openblas-0.3.21.ebuild | 196 +++++++++++++++++ 3 files changed, 434 insertions(+)
