Reduce mul!
methods related to "banded" matrices
#49666
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was encouraged by @blegat to further reduce the number of
mul!
methods, so here we go. I think we can do this by defining larger "groups" of types, catch any multiplication where they are involved and redirect to its own multiplication function(!), so here it's_mul!
. This may be of interest to @dlfivefifty: I grouped together all the "banded" structured matrices (remember we discussed subtyping (some of) them toAbstractTriangular
), and called the groupBandedMatrix
. Currently, this is a simple union, but we may want to consider actually introducing an abstract type and make these subtype it. And we may want to call the "banded matrix-related"_mul!
bandedmul!
. I can guess you can see where this is going. Does that sound like a good direction or should we avoid any interference with*BandedMatrices.jl
?In the big scheme of things, we can then resolve ambiguities with other "groups"(like wrapped (typically dense) matrices à la triangular, upper Hessenberg) at the larger scale, and ambiguity resolution within the groups happens at the
_mul!
/bandedmul!
scale, so doesn't increase the number ofmul!
methods.This PR reduces the number of
mul!
methods from 88 to 67, but it excludes the triangular part, which is a huge source of methods. I''ll take care of that part in my triangular overhaul #43972.