Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple but inelegant fix for #16548 #16979

Merged
merged 1 commit into from
Jun 23, 2016
Merged

Conversation

Sacha0
Copy link
Member

@Sacha0 Sacha0 commented Jun 17, 2016

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) and factorize 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!

…ecking that that specialized method gets called, a simple if inelegant fix for #16548.
@StefanKarpinski
Copy link
Member

Thanks! Better an inelegant fix than nothing. As long as the behavior is fixed, we can come up with a more elegant fix later and backport it to 0.5.1.

@vtjnash
Copy link
Member

vtjnash commented Jun 23, 2016

But decoupling seems to make type inference an issue, so no dice?

yep, looks like this would require more aggressive Union splitting / method considerations to realize the output type is constant. @JeffBezanson maybe we could have abstract_call_gf_by_type consider more methods as long as all are returning the same leaftype?

@vtjnash vtjnash merged commit fbe6e5a into JuliaLang:master Jun 23, 2016
@Sacha0 Sacha0 deleted the backslashfix branch June 23, 2016 02:44
@Sacha0
Copy link
Member Author

Sacha0 commented Jun 23, 2016

Thanks for the review and merge!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants