[WIP] FillArrays extension #34
Draft
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.
This adds a package extension for FillArrays.jl to define specialized factorization overloads for certain types defined in that package, in particular
Zeros
that lazily represents a matrix of all zeros andEye
that lazily represents a square or rectangular identity matrix. We can of course support other FillArrays.jl types, but those are the ones I have a use case for and they are pretty simple so I focused on those for now.The idea is that where possible the factorizations return factors that are either
Zeros
orEye
if that can be known at compile time (i.e. in a type stable way).It looks like a lot of code, but the definitions are all pretty simple. The basic code pattern is that I overload
copy_input
andinitialize_output
to be no-ops since the objects are immutable, and then the factorization definitions construct the output types based on the sizes/axes of the inputs.I've marked this as work-in-progress because it depends on changes made in #32 to avoid code duplication in
default_algorithm
definitions, and also that PR will make it a little easier to implementleft_polar
/right_polar
(which still needs to be implemented). I also haven't implementleft_null
/right_null
and haven't testedleft_orth
/right_orth
, since this PR is already very big I may leave that for future work. However, it would still be good to get some feedback on the approach I'm using.