[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53700] eigs test failure related to ARPACK ge

From: Marco Caliari
Subject: [Octave-bug-tracker] [bug #53700] eigs test failure related to ARPACK generating real NaN rather than complex NaN+1i*NaN
Date: Mon, 23 Apr 2018 02:59:07 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0

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
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:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]