[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 #16, bug #53700 (project octave):

@Mike: I didn't see your post about Ubuntu 18.04 until now.  Your result is
different than what you reported from a different system, so technically it
isn't reproduced.  On the older system you have


>> imag(d)
ans =

   0.0000e+00
  -8.6837e-13
   8.6837e-13


and on Ubuntu 18.04 you have


>> d(idx)
ans =

   1.00000 + 0.00000i
   1.00000 - 0.00000i
   1.00000 + 0.00000i
   1.00000 - 0.00000i


So, I suspect that the algorithm is finding eigenvalues by iteratively solving
some equation that could result in a negative residual somewhere that results
in some imaginary pair, and if said residual is positive the result is a
single real value.  Just guessing, but these numerical algorithms are prone to
this sort of thing with a large space and lots of iterations.

In other words, my setup could be slightly different in terms of compilers and
libraries I installed that gives me a real 1.0 eigenvalue in the first
location rather than a complex 1.0 +- 0.0 pair.

When I think of this test, I don't know what it is supposed to reveal.  It's
sort of testing that realm of the algorithm where there is numerical
breakdown, i.e., it's analyzing the limitation of the algorithm and how it
falls apart for a larger, over-parameterized system.  Just exactly how the
algorithm starts to fail is highly specific to the numerical methods--very
chaotic in the sense that one tiny perturbation will produce some completely
different way it fails.  And to illustrate, let's change the allowed
iterations on my system


octave:25> A = magic (100) / 10 + eye (100);
octave:26> opts.v0 = (1:100)';
octave:27> opts.maxit = 100;
octave:28> d = eigs (A, 10, "sm", opts);
warning: eigs: Only 5 of the 10 requested eigenvalues converged
warning: called from
    eigs at line 268 column 18
octave:29> d(d==d)
ans =

   1.00000 + 0.00000i
   1.00000 - 0.00000i
   1.00000 + 0.00000i
   1.00000 - 0.00000i
   1.00000 + 0.00000i


The number of iterations is almost like a random stopping criteria.

Wouldn't it be more useful to have a test that is acting in a more robust
region of the algorithm?

    _______________________________________________________

Reply to this item at:

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

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