Fri 17 Mar 2017 04:56:49 PM UTC, comment #8:
I pushed the patch in bug #50546. Nice work Marco, closing out a 4-year old bug.
|
Fri 17 Mar 2017 12:28:52 PM UTC, comment #7:
Fixed in #50546.
|
Thu 16 Mar 2017 09:52:07 AM UTC, comment #6:
Taking the input matrices from #50546, you see that Octave gives
for the fourth case (shift-invert mode). With the modifications described in comment #1, I get
If there are no additional comments, I will make a patch.
(file #40014)
|
Wed 15 Mar 2017 12:12:23 PM UTC, comment #5:
Octave now works simply because for rows (A) < 9, eig is called instead.
|
Wed 16 Nov 2016 10:44:07 PM UTC, comment #4:
The original example here gives a different result with the current version of Octave
So at least something has changed with respect to this example since 3.6.4. If eigs is still not correct for some cases, please feel free to comment on this bug report or open a new bug report with details about what still is not working correctly.
|
Tue 17 Sep 2013 07:59:47 AM UTC, comment #3:
You are right, documentation requires positive semi-definite matrices but ARPACK performs quite badly.
For instance, matlab gives "error -9999 in dsaupd" with your example and the same would give Octave with the modification you suggested.
Marco
|
Mon 16 Sep 2013 09:45:51 AM UTC, comment #2:
ARPACK documentation in DSAUPD.f states that for `mode = 3`,
the requirement is
"""
Kx = lambdaM*x, K symmetric, M symmetric positive semi-definite
"""
Positive definiteness is not required here.
However, what I'm not sure is whether this is actually correct, as ARPACK appears to behave quite badly for this class of problems.
|
Mon 05 Aug 2013 12:15:06 PM UTC, comment #1:
Hi,
your example is not correct, since B is not positive definite. On the other hand, I think you are right and line 1275 (and 2238 and 3259) of eigs-base.cc should be changed to
as for the case ido == 2.
Marco
|
Fri 26 Jul 2013 01:25:53 PM UTC, original submission:
Consider the following problem:
This gives large residual norms of order 1. The generalized eigenvalue problem is apparently solved incorrectly.
The reason appears to be that in `eigs-base.cc` the routine EigsRealSymmetricMatrixShift does the following for IDO=-1
The ARPACK mode used is mode==3, for which the ARPACK DSAUPD documentation states
However, Octave is apparently computing here Y = inv[K - sigmaM]K, as in the Octave routine,
`m` is apparently the matrix K, and `b` the matrix M. Is this correct?
The issue probably doesn't occur in typical usage as the IDO=-1 seems to be emitted by ARPACK only in the initial steps.
|