eigen of diagonal Hermitian with Complex eltype

[thchr]

The following example

eigen(Hermitian(@SArray [1.0+0.0im 0.0+0.0im; 0.0-0.0im 2.0+0.0im]))

errors with output

julia> eigen(Hermitian(@SArray [1.0+0.0im 0.0+0.0im; 0.0-0.0im 1.0+0.0im]))
ERROR: MethodError: no method matching isless(::Complex{Float64}, ::Complex{Float64})
Closest candidates are:
  isless(::Missing, ::Any) at missing.jl:66
  isless(::PyCall.PyObject, ::Any) at C:\Users\tchr\.julia\packages\PyCall\ttONZ\src\pyoperators.jl:75
  isless(::Any, ::Missing) at missing.jl:67
  ...
Stacktrace:
 [1] <(::Complex{Float64}, ::Complex{Float64}) at .\operators.jl:260
 [2] _eig at C:\Users\tchr\.julia\packages\StaticArrays\VyRz3\src\eigen.jl:142 [inlined]
 [3] #_eigen#481 at C:\Users\tchr\.julia\packages\StaticArrays\VyRz3\src\eigen.jl:405 [inlined]
 [4] _eigen at C:\Users\tchr\.julia\packages\StaticArrays\VyRz3\src\eigen.jl:405 [inlined]
 [5] #eigen#478 at C:\Users\tchr\.julia\packages\StaticArrays\VyRz3\src\eigen.jl:400
[inlined]
 [6] eigen(::Hermitian{Complex{Float64},SArray{Tuple{2,2},Complex{Float64},2,4}}) at
C:\Users\tchr\.julia\packages\StaticArrays\VyRz3\src\eigen.jl:400
 [7] top-level scope at none:0

On the other hand, this seems to work for real-symmetric matrices with nonzero off-diagonals. Similarly, the error disappears if a real Hermitian matrix is wrapped instead, i.e. works fine for @SArray [1.0 0.0; 0.0 2.0]. So far, I've only seen this appear for complex Hermitian matrices with strictly zero off-diagonals.

This came up in a parametrization of a 2×2 Hamiltonian that happened to be strictly diagonal for certain input parameters.

[thchr]

From a cursory look it seems this might be fixable by just changing

StaticArrays.jl/src/eigen.jl

Line 142 in b81044a

if A11 < A22

to

if real(A11) < real(A22)

assuming that ordering by the real part of the eigenvalues is the desirable choice (that seems to become the default in v1.2.x for ordinary matrices?).
I can make a PR if any of the devs can confirm that the above is reasonable?

[c42f]

Thanks for the bug report!

That fix is almost right, but will still return the output as complex values. I'd suggest calling real() when extracting A11 and A22 instead: for supposedly Hermitian input it's wise to force the eigenvalues to be real and this is also what Base does.

A PR would be most welcome, don't forget to include tests for both cases of uplo. (Actually both diagonal special cases are the same and could usefully be factored into the same code block at the bottom of the function.)