Simple but inelegant fix for #16548 #16979
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.
This pull request contains a simple but inelegant fix for JuliaLang/LinearAlgebra.jl#333.
By inelegant I mean this fix: (1) replicates code nearly verbatim between
factorize
and\
in base/sparse/linalg.jl, and replicates some logic between those methods and\
in base/linalg/generic.jl; and (2) includes a brittle test, almost certain to break if someone eliminates the code replication between the two preceding\
methods. (A note on the test's brittleness and expected eventual removal appears adjacent to the test.)Hence, though this fix may serve for the immediate future, eventually a better approach should replace it. A couple thoughts on better approaches:
A little metaprogramming could superficially eliminate the code replication between
factorize
and\
in base/sparse/linalg.jl, but those methods are short enough that the likely net impact of such metaprogramming would be obfuscation.Taking a step back,
\
classifies the LHS, factors the classified LHS, and then solves a system with the factored LHS.factorize
classifies the LHS and then factors the classified LHS. Of course somehow decoupling classification, factorization, and solution, then composing those elements to form\
(both dense and sparse) andfactorize
from the same code, would be ideal. But decoupling seems to make type inference an issue, so no dice?@andreasnoack @tkelman, other thoughts? Should this be discussed immediately, or should a simple fix like this one stand for now and additional discussion be deferred to another day/thread?
Best!