Loosen type-constraints don't enforce <:AbstractVector
#1033
Conversation
|
@vchuravy Is it not easier to do a "wrapper" that is an AbstractVector like I did in the documentation? I am scared to open a can of worms by relaxing the type. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1033 +/- ##
==========================================
+ Coverage 94.68% 97.64% +2.96%
==========================================
Files 45 49 +4
Lines 8027 9463 +1436
==========================================
+ Hits 7600 9240 +1640
+ Misses 427 223 -204 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Perhaps, but @lcw GridArray is a wrapper type... So it felt a bit silly to add a second wrapper type to present a vector to Krylov.jl |
|
I can understand that but can you show me what is doing |
| :(b::AbstractArray{FC})) | ||
|
|
||
| def_optargs_gmres = (:(x0::AbstractVector),) | ||
| def_optargs_gmres = (:(x0::AbstractArray{FC}),) |
There was a problem hiding this comment.
We don't to force FC because sometimes we warm-start from a solution in lower precision.
We could use a direct solver in Float32 to compute a very good approximate and then get more digits with a Krylov solvers.
2 participants
@lcw and I just run into a case where we have a data-structure
GridArraythat for the purpose of Krylov.jl acts like a Vector and we have defined the Krylov custom workspace API for,but for other reasons presents as
AbstractArray{Float64, 2}.IIRC the last time we spoke about this, there was an argument that the reason why Krylov.jl has this type constraint is so that the block-gmres API can use Matrix as an input.