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
We have currently two PRs in the pipeline that are breaking and therefore require a major release. So I thought we should collect ideas on what to put in there to not have major release every month or so. Clearly, we will have
Introduce specific show methods, add Base.parent overload #87 with the new show methods (I guess the only way to really get a feeling for whether it's good or not is to start using it and collect "annoyed" feedback, otherwise I feel this is too distant to form an opinion just by reviewing the PR)
a nice Documenter documentation, which then could nicely address Relation to other libraries #98 (That shouldn't be too hard: I'm planning to mainly cut our long README into more digestible pieces as a first approach.)
Anything else? Of course, if some hot PR comes in, there's nothing that stops us from merging it and releasing another v2.x. I'd hope to finish this some time in late August/early September. Any contributions/PRs/suggestions are more than welcome.
Have a good (rest of the) summer everyone!
EDIT:
I think we should relax the type of the output variable in the mul!s to AbstractVecOrMat. The following works perfectly fine with matrices in LinearAlgebra:
using LinearAlgebra
mul!(rand(5,1), rand(5,5), rand(5))
Gentle bump. What remains to be done is to decide if we want the constructor LinearMap(::Number, m, n) for FillMaps (or whether this is too close to UniformScaling-like maps) and a potential overhaul. I should add that the package is now basically 100% tested, so we might have a performance-oriented overhaul after we release v3.0.
We have currently two PRs in the pipeline that are breaking and therefore require a major release. So I thought we should collect ideas on what to put in there to not have major release every month or so. Clearly, we will have
Left vector multiply #100
Get rid of A*_mul_B! #97
Furthermore, I'd suggest to include
Anything else? Of course, if some hot PR comes in, there's nothing that stops us from merging it and releasing another v2.x. I'd hope to finish this some time in late August/early September. Any contributions/PRs/suggestions are more than welcome.
Have a good (rest of the) summer everyone!
EDIT:
mul!
s toAbstractVecOrMat
. The following works perfectly fine with matrices inLinearAlgebra
:TODO:
document conversion logic(not sure that's of general interest)FillMap
sThe text was updated successfully, but these errors were encountered: