Closed kcf-jackson closed 8 years ago
Thanks for the report.
It seems that you want to calculate the smallest eigenvalues of G
by specifying sigma = 0
, but G
actually has a zero eigenvalue. In general you cannot specify a sigma
that equals any one of the eigenvalues of matrix, so if your matrix is guaranteed to be nonnegative definite, you can use
eigs_sym(G, 3, sigma = -1)
to get the eigenvalues that are closest to -1, which are essentially the smallest eigenvalues of G
.
Thanks for the prompt reply, that makes a lot of sense. The results are now stable with respect to the same input.
However, I noticed some strange behaviour with setting the sigma value. My matrix should be non-negative definite, but the results vary unexpectedly. The differences between the second line and the fourth line are negligible, but the third line has 1 non-zero eigenvalue more than the others.
Given that all eigenvalues are positive, the smallest 3 eigenvalues should be the same when I change sigma from -0.99 to -1 to -1.01. But it seems sigma affected the calculation but not just the selection of the eigenvalues and eigenvectors.
Thanks.
This should be a bug. I'll take a look. Thanks for reporting this.
I've retried this example and come up with the following conclusion: the algorithm that RSpectra
uses is not good at detecting eigenvalues that are "clustered" (i.e., too close to each other). In your example, if we set the sigma
too far away from zero, e.g. -1, the transformed eigenvalues will be approximately 1, 1, and 0.9997175(=1/(1+2.825890e-4)), which are too indistinct. As a result, one of the eigenvalues (=1) was kind of "masked" by others.
Therefore, when we set sigma
, we should make it as close to zero as possible but also avoid numerical singularity, so the sigma = -1
advice I gave was a bad one. Instead, you may choose for example sigma = -1e-6
or sigma = -1e-7
and you should get the correct solutions.
Thanks. I think that'll do.
It seems the selection of eigenvalues and eigenvectors of 'eigs_sym' are unstable? (note that d = 2 below)
I cross-checked the result with the "eigen" function from the base package. The results there are stable. (so it's probably not a data issue.)
I attached the data for your information. It's in binary format; one can use the "load" function to read the file. Thanks. big_matrix.zip