[Octave-bug-tracker] [bug #53700] eigs test failure related to ARPACK generating real NaN rather than complex NaN+1i*NaN

[Marco Caliari]

Follow-up Comment #24, bug #53700 (project octave):

@Dan: I try to make a cumulative answer to your deep analysis. The main
"problem" in ARPACK is a proper choice of nev (number of desired eigenvalues,
k in eigs) and ncv (dimension of the Krylov subspace of approximate eigenpairs
(p in eigs). As written at the end of section 2.3.3 of Arpack User's Guide,
"it is best to avoid setting nev in such a way that will split clusters of
eigenvalues". The choice 10 is then to avoid (but it was made in order to
produce a failure!). Later "as a rule of thumb, ncv >= 2*nev is reasonable".
ncv=2*nev is the choice made in eigs. Therefore, requiring 10 eigenvalues
correspond to using 20 as Krylov subspace. Requiring 50 eugenvalues correspond
to using 100 as Krylov subspace, which is the dimension of the original
matrix: therefore, you are pretty sure that you find all the eigenvalues. You
can force a new ncv by setting opts.p="something larger than 20" and keeping
k=10. Solution will improve.
Z = B * X (that is Z = X, in our case) is done in dnaup2, which is called be
dnaupd.
Matlab can find only few eigenvalues, too.

Therefore, although it is not possible to exclude a hidden bug in the chain
eigs.m, __eigs__.cc, eigs-base.cc, arpack, "Why when we request less
eigenvalues do we have a less robust situation?" can be explained as above and
it is not a clear symptom of a bug.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53700>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/