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

[Dan Sebald]

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

At first I thought there was something wrong about the system setup, i.e.,
this large matrix with numbers much larger than eye() caused an instability
somewhere.  However, experimenting a bit, I don't quite understand what is
happening with the number of eigenvalues.  Going back to the original test:


octave:2> A = magic (100) / 10 + eye (100);
octave:3> opts.v0 = (1:100)';
octave:4> opts.maxit = 10;
octave:5> d = eigs (A, 10, "sm", opts);
warning: eigs: Only 1 of the 10 requested eigenvalues converged
warning: called from
    eigs at line 265 column 18
octave:6> d(d==d)
ans =  1.00000


However, change the requested number of eigenvalues from 10 to 100, i.e., all
the eigenvalues and surprisingly there is no convergence problem:


octave:7> d = eigs (A, 100, "sm", opts);
octave:8> d(d==d)
ans =

       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 -     0.00000i
       1.00000 +     0.00000i
       1.00000 +     0.00000i
   -2885.60700 +     0.00000i
    2887.60700 +     0.00000i
   50006.00000 +     0.00000i


Doing sum(A), every value is 50006, and it probably isn't a coincidence that
the last eigenvalue in the list is 50006.  Seems reasonable.

So I'm confused.  Why when we request less eigenvalues do we have a less
robust situation?  Typically when one puts a restriction on an algorithm it
leads to improved robustness...say if we know some eigenvalues are problematic
we might choose sigma and the number of eigenvalues in a way that squeezes
those problematic eigenvalues out of the picture.

    _______________________________________________________

Reply to this item at:

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

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