-
-
Notifications
You must be signed in to change notification settings - Fork 46
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
linalg.eigh incorrect results for complex data on osx-arm64 #287
Comments
Thanks for the report @jcmgray. This looks suspiciously similar to numpy/numpy#21950, which ended up being a
That's a little odd. Either way, |
I can confirm the problem with
|
There are other test failures. Here is the
And for
With |
Yes likely a separate issue, but thought I'd note that at least on my Mac the default install (i.e, this exact command) is the |
Hmm, no idea why. That's a significant performance penalty, so I'd consider getting |
Seems like I need to get the blas testing series up to speed for 1.24.
openblas should be the default also on osx, and in any case it should definitely work. However, you're mixing channels (default and conda-forge), which is a very likely cause for these problems. Could you please try
and then either a new environment, or using |
Ah sorry yes you are right, thanks for the suggestion. |
I am using a Mac mini M1 and recently found this issue. It works fine with |
Experienced the same problem on numpy 1.26.0 with accelerate blas. |
Solution to issue cannot be found in the documentation.
Issue
On osx-arm64 with numpy==1.24 installed from conda-forge,
np.linalg.eigh
produces incorrect results for complex data types:Other linalg such as svd appears to be working (though I haven't checked exhaustively).
I have checked this with:
blas=*=acclerate
blas=*=netlib
(Can't check with
blas=*=openblas
as this doesn't appear to work more generally)Using
numpy
from pypi the code is working fine. Thus raising the issue here assuming it is something to do with the linked lapack, but apologies if this should be in the mainnumpy
repo.Possibly related to #21950, thought the issue here is not simply normalization of the eigenvectors.
Installed packages
Environment info
The text was updated successfully, but these errors were encountered: