Open spacedome opened 5 years ago
anyone have thoughts on this? I need to use BigFloat with GMRES
IterativeSolvers.idrs
works, which is also a Krylov subspace method for solving large nonsymmetric systems of linear equations (http://ta.twi.tudelft.nl/nw/users/gijzen/IDR.html).
@chriscoey As a workaround you can impliment gemv!
for BigFloat with something like this:
function BLAS.gemv!(tA, alpha, A::AbstractMatrix{BigFloat}, x, beta, y)
y .= alpha .* (if tA == 'T' transpose(A) elseif tA == 'C' A' else A end) * x .+ beta .* y
end
After looking through more of the open issues for LinearAlgebra, the generic equivalent of gemv!
is supposed to take the form of mul!
or muladd!
or something like that, but the name and API hasn't been finalized, see https://github.com/JuliaLang/julia/issues/23919 for details. It might make sense to wait on this issue until LinearAlgebra fixes this?
That's right, and there is also #206 here. The "drawback" of the workaround above is that (if tA == 'T' transpose(A) elseif tA == 'C' A' else A end) * x
allocates a vector at each call.
Currently the implementations of BiCGStab and GMRES use methods in LinearAlgebra that do not have generic fallbacks.
BiCGStab makes an explicit call to
BLAS.gemv!
which is implemented only for real and complex floats. I know that the LinearAlgebra package tries to have generic fallback methods, so I am not sure if this is an issue of IterativeSolvers, but currently the code does not work unless I implementgemv!
for whatever type I'm using.GMRES also calls
BLAS.gemv!
but even if this is fixed, when computing the FastHessenberg the LinearAlgebra functiongivensAlgorithm
is called, which is only defined for real and complex. Fixing thegemv!
means GMRES would work with BigFloats and other real and complex types, but I am not sure how generic Givens rotations could be implimented.Here is an example using Quaternions.jl
this gives the following error:
The same error occurs with BigFloats.
Should LinearAlgebra have a generic fallback for
gemv!
? Should this package have a fallback for calls togemv!
based on type? I'm not entirely sure of the best way to do the latter, but it shouldn't be difficult, I can try to make a pull request if wanted. For GMRES, I'm not aware of a way to generalize Givens rotations, so maybe it should be explicit about only accepting real and complex? Not sure how important generic implimentations are to other people using this package.