You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be nice if the various solvers had the same interface to create iterators (which would reduce the amount of boilerplate in e.g. https://github.com/haampie/JacobiDavidson.jl to support different solvers).
If we could also have a reset! function to set new right-hand-sides and reinitialize all helper structures as well, that would be awesome.
Finally, I wonder if iterative "factorizations" are of interest? I.e. a struct that provides an implementation of ldiv! that under the hood uses one of the solvers from IterativeSolvers.jl. I started trying something out here, but I think it would possibly find a better home in IterativeSolvers.jl.
I think it would be nice if the various solvers had the same interface to create iterators (which would reduce the amount of boilerplate in e.g. https://github.com/haampie/JacobiDavidson.jl to support different solvers).
I've had to introduce some of that boilerplate in my projects a couple of times now, specifically to create allocation-free versions of CG, LSQR and LSMR. With a little extra effort, I think I could adapt what I have to implement iterators for those three methods. I'd like to contribute but don't want to duplicate work if other people already have (better) implementations.
Related to #166
I think it would be nice if the various solvers had the same interface to create iterators (which would reduce the amount of boilerplate in e.g. https://github.com/haampie/JacobiDavidson.jl to support different solvers).
If we could also have a
reset!
function to set new right-hand-sides and reinitialize all helper structures as well, that would be awesome.Finally, I wonder if iterative "factorizations" are of interest? I.e. a struct that provides an implementation of
ldiv!
that under the hood uses one of the solvers from IterativeSolvers.jl. I started trying something out here, but I think it would possibly find a better home in IterativeSolvers.jl.Ping @haampie
The text was updated successfully, but these errors were encountered: