`cupy.linalg.eigh` returns `nan` for zero matrix

Description

The eigenvalues and eigenvectors of a zero matrix are nan. Is this the expected behavior?

To Reproduce

import cupy as cp
x = cp.zeros((2, 2))
print(cp.linalg.eigh(x))

gives

(array([nan, nan]), array([[nan, nan],
       [nan, nan]]))

The equivalent in numpy:

import numpy as np
x = np.zeros((2, 2))
print(np.linalg.eigh(x))

gives

(array([0., 0.]), array([[1., 0.],
       [0., 1.]]))

Installation

Conda-Forge (conda install ...)

Environment

OS                           : Linux-5.13.0-30-generic-x86_64-with-glibc2.17
Python Version               : 3.8.12
CuPy Version                 : 10.2.0
CuPy Platform                : NVIDIA CUDA
NumPy Version                : 1.21.5
SciPy Version                : 1.8.0
Cython Build Version         : 0.29.28
Cython Runtime Version       : None
CUDA Root                    : /home/stavros/anaconda3/envs/testcupy
nvcc PATH                    : None
CUDA Build Version           : 11020
CUDA Driver Version          : 11060
CUDA Runtime Version         : 11060
cuBLAS Version               : (available)
cuFFT Version                : 10600
cuRAND Version               : 10209
cuSOLVER Version             : (11, 3, 2)
cuSPARSE Version             : (available)
NVRTC Version                : (11, 6)
Thrust Version               : 101000
CUB Build Version            : 101000
Jitify Build Version         : 0ea2960
cuDNN Build Version          : None
cuDNN Version                : None
NCCL Build Version           : None
NCCL Runtime Version         : None
cuTENSOR Version             : 10400
cuSPARSELt Build Version     : None
Device 0 Name                : NVIDIA GeForce GTX 1650 with Max-Q Design
Device 0 Compute Capability  : 75
Device 0 PCI Bus ID          : 0000:01:00.0

Additional Information

There are a few other cases for which the output of cupy.linalg.eigh does not agree with numpy. For example:

import numpy as np
import cupy as cp


m1 = np.array([[0, 0, 0, 1],
               [0, 0, 0, 0],
               [0, 0, 0, 1],
               [1, 0, 1, 0]])
m2 = cp.asarray(m1)

eigvals1, eigvecs1 = np.linalg.eigh(m1)
eigvals2, eigvecs2 = cp.linalg.eigh(m2)
eigvals2, eigvecs2 = eigvals2.get(), eigvecs2.get()

print(eigvals1)
print(eigvals2)
print()
print()
print(eigvecs1)
print()
print(eigvecs2)

gives

[-1.41421356e+00 -6.07153217e-18  0.00000000e+00  1.41421356e+00]
[-1.41421356e+00  0.00000000e+00  7.54604712e-17  1.41421356e+00]


[[-5.00000000e-01 -7.07106781e-01  0.00000000e+00  5.00000000e-01]
 [ 0.00000000e+00  0.00000000e+00 -1.00000000e+00  0.00000000e+00]
 [-5.00000000e-01  7.07106781e-01  0.00000000e+00  5.00000000e-01]
 [ 7.07106781e-01  4.85722573e-17  0.00000000e+00  7.07106781e-01]]

[[-5.00000000e-01  0.00000000e+00  7.07106781e-01 -5.00000000e-01]
 [ 0.00000000e+00 -1.00000000e+00  0.00000000e+00  0.00000000e+00]
 [-5.00000000e-01  0.00000000e+00 -7.07106781e-01 -5.00000000e-01]
 [ 7.07106781e-01  0.00000000e+00  6.92100090e-17 -7.07106781e-01]]

In this case both results are mathematically correct, it is just that the degenerate eigenvectors are returned in different order and some signs are different. I am not sure if this is expected behavior.

[leofang]

It’s a known issue (nvbugs 3496875) expected to be fixed in CUDA 11.7.

[emcastillo]

Yeah, this is a cuda issue, stick to an older toolkit version meanwhile 😃 eigh just directly calls cusolver so there’s nothing we can do in CuPy right now.