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: Base.LinAlg.ARPACKException("unspecified ARPACK error: -9999")
in aupd_wrapper(::Type{T}, ::Base.LinAlg.#matvecA!#67{Array{Float64,2}},
::Base.LinAlg.##64#71{Array
{Float64,2}}, ::Base.LinAlg.##65#72, ::Int64, ::Bool, ::Bool, ::String,
::Int64, ::Int64, ::String, :
:Float64, ::Int64, ::Int64, ::Array{Float64,1}) at ./linalg/arpack.jl:53
in #_eigs#60(::Int64, ::Int64, ::Symbol, ::Float64, ::Int64, ::Void,
::Array{Float64,1}, ::Bool, ::B
ase.LinAlg.#_eigs, ::Array{Float64,2}, ::Array{Float64,2}) at
./linalg/arnoldi.jl:271
in (::Base.LinAlg.#kw##_eigs)(::Array{Any,1}, ::Base.LinAlg.#_eigs,
::Array{Float64,2}, ::Array{Floa
t64,2}) at ./<missing>:0
in #eigs#54(::Array{Any,1}, ::Function, ::Array{Float64,2},
::Array{Float64,2}) at ./linalg/arnoldi.
jl:80
in (::Base.LinAlg.#kw##eigs)(::Array{Any,1}, ::Base.LinAlg.#eigs,
::Array{Float64,2}, ::Array{Float6
4,2}) at ./<missing>:0
and since SciPy ends up with the same conclusion I conclude that the issue
is ARPACK. Matlab is doing something else because they are able to handle
this problem.
Given that 0.5 is almost release, I'll not spend more time on the issue on
0.4. Thought, if anybody is able to figure out what is going on, please let
us know.
On Friday, August 5, 2016 at 8:47:26 AM UTC-4, Madeleine Udell wrote:
>
> Setting `which=:LR, nev=1` does not return the generalized eigenvalue with
> the largest real parts, and does not give a warning or error:
>
> n = 10
> C = eye(n)
> A = zeros(n,n)
> A[1] = 100
> A[end] = -100
> @assert eigs(A, C, nev=1, which=:LR)[1][1] == maximum(eigs(A, C)[1])
>
> Am I expected to set nev greater than the number of eigenvalues I truly
> desire, based on my intuition as a numerical analyst? Or has eigs broken
> its implicit guarantee?
>
>
