[Octave-bug-tracker] [bug #31479] Crash & bugs in eigs

[John W. Eaton]

Update of bug #31479 (project octave):

                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #1:

I'm copying David Bateman on this bug report because he wrote the eigs
function and the interface to arpack for Octave.  Perhaps he will have some
insight.

I can reproduce this problem on a Debian system with the current development
sources for Octave.

I don't have a complete fix for the problem yet, but maybe the following info
will help someone else to solve the problems.

I'm attaching a file, arpack-bug.tar.gz that is a pared-down version of the
function that Octave uses to do this particular eigs call.  In the
arpack-bug.cc file there are a couple of comments about array dimensions that
are different in Octave from what they are in arpack-bug.cc.  When I use the
values from Octave, I see warnings from valgrind (see the
valgrind-output-before-changes file in the tarball) and those warnings
disappear after making the changes.

I don't know what causes arpack to sometimes find an extra eigenvalue.  I
thought it might be the random value of resid that is used in the initial call
to dnaupd, but even when that value is fixed as in my arpack-bug.cc file, it
still sometimes finds a complex pair instead of a single real value.  And
valgrind is not telling me anything about uninitialized values.  

OK, I see now that if info is zero on the first call to dnaupd, it will use
its own random number generator to initialize the resid vector.  So that
explains why I was getting apparently random results when I thought I was
using the same input values on each call.  And I can confirm that by setting
info to 1 on the first call instead of 0, and setting the same initial values
for resid on each initial, arpack will return the same values each time. 
Unfortunately, it still may converge to a complex conjugate pair instead of a
single real value, depending on the values selected for resid.  So I still
don't see how to fix the problem and ensure that arpack will converge to the
same *correct* point each time.


(file #21848)
    _______________________________________________________

Additional Item Attachment:

File name: arpack-bug.tar.gz              Size:52 KB


    _______________________________________________________

Reply to this item at:

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

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