`eigs` fails for sparse Hermitian `ComplexF32` matrices when using nonzero `sigma`

[yakovbraver]

using LinearAlgebra, SparseArrays, Arpack
M = sprand(ComplexF32, 30, 30, 0.5) |> hermitianpart
eigs(M, nev=1, sigma=1.0f0, which=:LM)

gives

ERROR: MethodError: no method matching bunchkaufman!(::Hermitian{ComplexF32, SparseMatrixCSC{ComplexF32, Int64}}, ::Bool; check::Bool)

Closest candidates are:
  bunchkaufman!(::StridedMatrix{var"#s124"} where var"#s124"<:Union{Float32, Float64, ComplexF64, ComplexF32}, ::Bool; check)
   @ LinearAlgebra ~/.julia/juliaup/julia-1.10.5+0.aarch64.apple.darwin14/share/julia/stdlib/v1.10/LinearAlgebra/src/bunchkaufman.jl:111
  bunchkaufman!(::Hermitian{<:Union{ComplexF64, ComplexF32}, <:StridedMatrix{T} where T}, ::Bool; check)
   @ LinearAlgebra ~/.julia/juliaup/julia-1.10.5+0.aarch64.apple.darwin14/share/julia/stdlib/v1.10/LinearAlgebra/src/bunchkaufman.jl:105
  bunchkaufman!(::Union{Hermitian{var"#s121", var"#s120"}, Symmetric{var"#s121", var"#s120"}, Symmetric{Complex{var"#s121"}, var"#s120"}} where {var"#s121"<:Union{Float32, Float64}, var"#s120"<:(StridedMatrix{T} where T)}, ::Bool; check)
   @ LinearAlgebra ~/.julia/juliaup/julia-1.10.5+0.aarch64.apple.darwin14/share/julia/stdlib/v1.10/LinearAlgebra/src/bunchkaufman.jl:99

For ComplexF64, the method works as expected. If one does M .+= M' instead of using hermitianpart, the problem persists.
Relatedly, I think #131 was failing because of Float32, but I cannot reproduce that issue (works fine for me; probably fixed).
Tested on Arpack v0.5.4 and v0.5.3.

versioninfo()

Julia Version 1.10.5
Commit 6f3fdf7b362 (2024-08-27 14:19 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: macOS (arm64-apple-darwin22.4.0)
  CPU: 12 × Apple M2 Pro
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
Threads: 8 default, 0 interactive, 4 GC (on 8 virtual cores)

[yakovbraver]

OK, so this is resolved in the just-released Julia 1.11 since bunchkaufman and bunchkaufman! now work for any AbstractFloat 😀

[dkarrasch]

Hm, I'm not sure that's necessarily a good "fix": those generic algorithms are written for dense arrays, so performance on sparse arrays will be horrible, presumably.