octave-bug-tracker
[Top][All Lists]
Advanced

[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: Dan Sebald
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 04:10:11 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

Oh, so the reason for the less robust system for NEV=10 is that the Krylov
subspace dimensionality is not even near the cardinality of the largest
eigenvalue group, which is 97 in this case.  I.e., 97 eigenvalues of 1.0. 
That's what the algorithm is struggling with.  On the other hand, had we
chosen a system for which there were more variation in the eigenvalues, e.g.,
1.0 1.0 3.0 3.0 3.5 2-2j 2+2j, etc., and used a Krylov subspace of 10 then
we'd get good convergence.

Going the other direction, increasing NEV to 50 (or is it p=50?) makes the
Krylov subspace nearer to the size of the largest eigenvalue group in this
case.

Thanks for the explanation.

Would there be any other type of more assured test?  Say, if instead of
looking for "sm" eigenvalues, we looked for "lm".  The largest eigenvalues
have a group cardinality of 1 or 2 and therefore those few really large
eigenvalues should converge nicely on all systems, compilers and linear
algebra libraries with a choice of NEV=10.  I'm seeing


octave:32> d = eigs (A, 10, "lm", opts);
octave:33> d
d =

   50006.00000
    2887.60700
   -2885.60700
       1.00000
           NaN
           NaN
           NaN
           NaN
           NaN
           NaN


But that too ends up being not complex, so I don't know if that gets us
anywhere different.

How about choosing an odd number for NEV?  Will that force there to be a
conjugate pair somehow?


octave:34> d = eigs (A, 9, "lm", opts);
octave:35> d
d =

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


What do others see for such tests?  Is it just as arbitrary?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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