-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: complex determinants broken with openblas 0.3.22 #18208
Comments
Are the NumPy versions the same? Asking to eliminate f2py sneaking in with the Fortran stuff. |
I can only see these changes numpy/numpy#22025 & OpenMathLib/OpenBLAS#3924 that might be relevant on OpenBLAS regarding By the way, why are we even using fortran files for these things ? After so many years still finding out new quirks in linalg folder 😃 |
I've tested with several numpy versions, including the published wheels; does not seem to make a difference. |
See also OpenMathLib/OpenBLAS#3976 |
I would hope that examples like the OP presented would be present in a test suite. We should definitely add something like this to the scipy test suite. |
Yes, we caught it using SageMath's test suite. |
LAPACK does not have a function to compute determinants. This means that one of LAPACK factorisation routines, e.g. LU decomposition, or whatever scipy is using here, got buggy. Can scipy people tell us how they do it, what are they calling ? Perhaps experimenting with calling various matrix decompositions will tell more. |
The code says:
The callstack is something like: det --> zdet_r --> zdet_c --> call to zgetrf |
I'll fix that today or tomorrow evening and get rid of the custom fortran files and call |
apologies for hijacking the issue but could anyone reading (especially for conda users with MKL.), can run the following snippet and post the plot here? I kept it comparable to the existing implementation with the excessive checks and whatnot; # pip install perfplot
import perfplot
import numpy as np
import scipy.linalg as la
from scipy.linalg._decomp import _asarray_validated
from scipy.linalg import get_lapack_funcs
from scipy.linalg._misc import _datacopied
def mydet(a, overwrite_a=False):
a1 = _asarray_validated(a, check_finite=True)
if len(a1.shape) != 2 or a1.shape[0] != a1.shape[1]:
raise ValueError('expected square matrix')
overwrite_a = overwrite_a or _datacopied(a1, a)
trf = get_lapack_funcs('getrf', dtype=a1.dtype)
# det(a) = det(a.T) but can overwrite if dtype is compatible to (s,d,c,z)
if a1.flags['C_CONTIGUOUS']:
lu, piv, info = trf(a1.T, overwrite_a=overwrite_a)
else:
lu, piv, info = trf(a1, overwrite_a=overwrite_a)
if info < 0:
raise ValueError(f'illegal value in {-info}-th argument of internal '
'det.getrf')
a_det = 1.
# piv is 0-indexed
for x in range(a1.shape[0]):
a_det *= lu[x, x]*(1. if piv[x] == x else -1.)
return a_det
perfplot.show(
setup=lambda n: np.random.rand(n, n),
# setup=lambda n: np.random.rand(n, n) + np.random.rand(n, n)*-2j,
kernels=[la.det, mydet],
labels=["SciPy", "this PR"],
n_range=[3*x for x in range(1, 100, 3)],
logx="auto",
logy="True",
equality_check=np.allclose,
xlabel="input size (n)",
) My machine is again smoking inappropriate stuff whenever partying with LAPACK, pure python is almost the same performance (which is understandable since most time is spent on getrf) but just wanted to make sure . |
|
these benchmarks are obviously very sensitive w.r.t. number of threads, and MAX_THREADS=2 is serioisly low. How about at least 8? And it's not at all clear what's used for this PR. |
multithreading does (should) not start until some value later in the plot. That kinda common jump is often L2 cache limit. But one can never be sure. "This PR" is the one I'm about to prepare which is the mydet function. It's just a label, see the code above. |
All feedback is welcome in the linked PR. I tried to address the shortcomings I could gather from various comments and issues. |
|
Describe your issue.
scipy.linalg.det
is broken when scipy is built from source with the just-released openblas 0.3.22.Tested on macOS x86_64.
Ref: sagemath/sage#35371
Reproducing Code Example
Error message
SciPy/NumPy/Python version and system information
The text was updated successfully, but these errors were encountered: