Right, ARPACK only enforces the projection for the generalized problem. I
think your example relies on roundoff error in the orthogonalization step
to populate the null space.
With regard to semi-definite B (or C in the OP), the shifted version of the
algorithm (mode 3 in ARPACK) will work for
Oh gosh! It's terrible that we're trying to factor the second matrix. It's
quite common that the second matrix in a generalized eigenvalue problem is
not positive definite.
If we can't get this fixed soon, I'm going to have to resort to Matlab for
my current project...!
On Sat, Aug 6, 2016 at
The 0.5 behavior is the same as Fortran, and is technically correct.
ARPACK cannot create more (orthogonal) Krylov vectors than the rank of the
matrix A,
so your example needs the additional keyword ncv=2. This doesn't seem to be
adequately documented in arpack-ng either. The 0.4 behavior
Looked a bit more into this. It was great to be able use Gallium for this
by the way. I was able to figure out what the issue is on 0.4. We are not
checking error codes returned from ARPACK. The check was added in
Actually: I'm not sure we should chalk the error up to ARPACK. Julia 0.4 is
able to produce a (correct, I think) answer to
eigs(A, C)
but 0.5 gives an ARPACK error. I don't suppose ARPACK changed between Julia
versions...!?
On Sat, Aug 6, 2016 at 1:54 AM, Madeleine Udell
Andreas, thanks for the investigation. I'll use 0.5 for now, and hope the
real problems I encounter are within the capabilities of ARPACK.
It's embarrassing to be bested by Matlab...
On Fri, Aug 5, 2016 at 9:23 PM, Andreas Noack
wrote:
> I've looked a bit into
I've looked a bit into this. I believe there is a bug in the Julia wrappers
on 0.4. The good news is that the bug appears to be fixed on 0.5. The bad
news is the ARPACK seems to have a hard time with the problem. I get
julia> eigs(A,C,nev = 1, which = :LR)[1]
ERROR: