Ground state eigenvector different for different eigen solvers (differs by negative sign in the elements). Does it matter?

Question

Here is some code that hopefully clearly illustrates what I'm doing:

>>> sp.linalg.eig(d)[0].real; sp.linalg.eigh(d)[0]; d; sp.linalg.eig(d)[1]; sp.linalg.eigh(d)[1]
array([ 1., -1.])
array([-1.,  1.])
matrix([[ 0, -1],
        [-1,  0]])
array([[ 0.70710678,  0.70710678],
       [-0.70710678,  0.70710678]])
array([[-0.70710678, -0.70710678],
       [-0.70710678,  0.70710678]])

To explain the code a little, the first two array()'s are the eigenvalues from eig() and eigh() respectively, where the latter is only for Hermitian matrices. Then I show the matrix d, and then the eigenvectors are shown as the columns of the following two matrices, in the same order as the eigenvalues.

Here, what I'm doing is taking a matrix d which in this case is simply $\sigma_x$, the Pauli x-spin matrix. I'm doing adiabatic quantum simulation, so I'm getting the ground state here of a transverse magnetic field for a 1-qubit case. Higher qubit cases have initial state vector that corresponds to the lowest energy for:

$D = -\sum_i^N I \otimes I \otimes ...\otimes ~\sigma_x^i \otimes...\otimes ~I$

So what I'm doing now is using the general LAPACK eigensolver zgeev with the eig() call and zheevd with the eigh() call, which is general and Hermitian solvers, respectively.

Why do I get the ground state eigenvector as one thing from eig(), but with eigh() I get the same thing but with an overall negative? And does it matter at all?

It's worth noting that this problem does NOT arise if I say $D$ has positive values instead of negative ones. That bit really confuses me.

Answer 1

Eigenvector solutions to the standard eigenvalue problem formulation ($A\mathbf{v}=\lambda\mathbf{v}$) are unique up to a constant multiplier. It is clear that if there exists an eigenvector solution $\mathbf{v_a}$ which satisfies $A\mathbf{v_a}=\lambda\mathbf{v_a}$, then for any real\complex scalar $k$, $\mathbf{v_b}=k\mathbf{v_a}$ is also valid simply because $A\mathbf{v_b}=kA\mathbf{v_a}=k\lambda\mathbf{v_a}=\lambda\mathbf{v_b}$.

Therefore, it is not surprising that two different eigensolvers are returning the same eigenvector scaled differently. You must define your own renormalization procedure if you wish to completely uniquely define the eigenvectors (for instance: always force one of the components of the eigenvector to be 1 by dividing the resulting eigenvector with the value of that component.)

Answer 2

The other answers suggest normalizing eigenvectors so that their first component is positive, but this seems bad advice to me: if the computed eigenvectors are v = (1e-17, 1) and w =(-1e-17, 1), then normalizing them to v_n = (1e-17, 1) and w_n =(1e-17, -1) and checking their distance with norm(v_n, w_n) identifies them as far apart when they are in fact very close to one another.

My advice is that you are looking at the problem at the wrong level: you don't need to normalize your output, you need to change the way in which you make comparisons between vectors. Compare two vectors $a,b$ by computing their angle, or correlation: $\frac{|a^Tb|}{\lVert a \rVert \lVert b\rVert}$. If this quantity is close to 1, then the two vectors differ only by a phase.

Answer 3

You can fix the eigenvectors to have the same sign in Python like this: eigvects = np.sign(eigvects[0,:]).transpose()*eigvects

That will fix the 1st eigenvector component to positive for all eigenvectors.

I can't figure out the LAPACK signing routine either vs ARPACK which would be nice to know so that eigh signs could be replicated, keeping your simulation predictable.

Answer 4

The above concern with a result of positive or negative 1e-17 as the first eigenvector value (which suggests a rounding error on essentially a 0 value could render your scaled eigenvector invalid) is not impacted by the ARPACK eigsh routine (Python, or eigs in MATLAB) - it consistently reproduces identical eigenvectors only differing by +/-1 scalar. If you use another method which may introduce rounding errors, I would suggest increasing precision to avoid that issue if it presents itself.