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

@Marco: Good suggestion.  I reached a similar conclusion because I think there
isn't anything wrong with setting up the routines.  It is simply that the
library function is behaving slightly different in terms of convergence:


  F77_INT k0 = k;  // original number of eigenvalues required
  F77_FUNC (dneupd, DNEUPD)
    (rvec77, F77_CONST_CHAR_ARG2 ("A", 1), sel, dr, di, z, n, sigmar,
     sigmai, workev,  F77_CONST_CHAR_ARG2 (&bmat, 1), n,
     F77_CONST_CHAR_ARG2 ((typ.c_str ()), 2), k, tol, presid, p, v, n,
iparam,
     ipntr, workd, workl, lwork, info2 F77_CHAR_ARG_LEN(1)
F77_CHAR_ARG_LEN(1)
     F77_CHAR_ARG_LEN(2));
  // On exit, if (and only if) rvec == true, k may have been increased by one
  // and be equal to ip(4), see dngets.

std::cerr << "ip(4) = " <<  ip(4) << "\n";
  if (! rvec && ip(4) > k)
    k = ip(4);


ip(4) is 1, not 3 in my case.  It could be that convergence of the first one
is solid, but the other two are tenuous and dependent on the compiler. 
Looking at what Mike listed:


>> imag(d)
ans =

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


if only that first eigenvalue is examined, then the followup code  that checks
for the imaginary component is not going to set "have_cplx_eig = true;".  It's
only the second and third cases where have_cplx_eig is set true in Mike's
case.

In addition to the isreal() check, how about testing that d(1) == 1.0 or
(1.0,0.0) in addition to the check on d(10)?  It seems that's the reliable
eigenvalue.

    _______________________________________________________

Reply to this item at:

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

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