BUG: Non-normalized eigenvectors in linalg.eigh for complex hermitian matrix on osx-arm64

Describe the issue:

The linalg.eigh function should return the ‘normalized eigenvectors’ of a symmetric or hermitian matrix. Below I used a simple symmetric matrix and calculated the determinant (which should be 1) and whether the two eigenvectors are normalized.

• When using dtype=float for the matrix, the results are correct.
• When using dtype=complex for the matrix, the eigenvectors are not normalized.

I did run the below code on several machines and only got the bug on my macbook m1 on arm64. When emulating the osx-64 numpy package, the result is correct. The concrete versions, which I checked, are listed below.

Reproduce the code example:

import numpy as np
# Forcing `matrix` to be of dtype=complex
matrix = np.array([[0,1+0j],[1,0]])
eigenvectors = np.linalg.eigh(matrix)[1]
# Check if `The array v of (column) eigenvectors is unitary`
print(1 - abs(np.linalg.det(eigenvectors)))
# Check explicitly if eigenvectors are normalized
print(1 - eigenvectors[:,0].T.conj()@eigenvectors[:,0])
print(1 - eigenvectors[:,1].T.conj()@eigenvectors[:,1])
# All outputs should be close to 0

Error message:

# OUTPUT on osx-arm64
-1.216802553763662
(-0.9999999999999998-2.2371143170757382e-17j)
(-1.707106781186547-3.251767952832691e-17j)

NumPy/Python version information:

Versions where the bug occurred

• 1.23.0 3.10.5 | packaged by conda-forge | (main, Jun 14 2022, 07:05:37) [Clang 13.0.1 ] numpy from conda-forge, osx-arm64
• 1.21.5 3.10.4 (main, Mar 31 2022, 03:37:37) [Clang 12.0.0 ] numpy from anaconda channel, osx-arm64

Other versions where the bug did not occur

• 1.22.3 3.10.4 (main, Mar 31 2022, 03:38:35) [Clang 12.0.0 ] Emulation of osx-64 on M1
• 1.21.4 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] x86_64 linux system

[aschelle]

I don’t have an osx-arm; could you please post the outputs of np.linalg.eigh(matrix), @aschelle?

CC @martin-frbg - any idea why eigenvectors on osx-arm for complex matrices might not get normalized correctly (regression between 0.3.18 & 0.3.20)?

Yes, here is the output for eigh:

>>> np.linalg.eigh(matrix)
(array([-1.,  1.]), array([[-0.70710678-0.70710678j,  0.70710678+1.20710678j],
   [ 0.70710678+0.70710678j,  0.70710678+0.5j       ]]))'''

Indeed, the real part looks as normalized, but the imaginary part makes no sense to me.

Hopping not to disturb the conversation, but: You are awesome 😃. Thank you all very much for your time and expertise. It’s a real pleasure following the discussion.

[martin-frbg]

Probably https://github.com/xianyi/OpenBLAS/issues/3654 - long-standing (unnoticed) bug in ThunderX2 DNRM2/ZNRM2 kernel that was exposed by my propagating said kernel to other performant (and less obscure) arm64 cpus in 0.3.19