-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
optimize and fix map/broadcast over Adjoint/Transpose vectors, take 2 #25238
Conversation
…and fix inference. (Take 2.)
The CI straight flush seems progressively more common! 🎉 |
Absent objections or requests for time, I plan to merge these changes midday tomorrow PT at the earliest. Thanks all! |
# | ||
# note that the caller's operation f operates in the domain of the wrapped vectors' entries. | ||
# hence the Adjoint->f->Adjoint shenanigans applied to the parent vectors' entries. | ||
map(f, avs::AdjointAbsVec...) = Adjoint(map((xs...) -> Adjoint(f(Adjoint.(xs)...)), parent.(avs)...)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given recent discussions shouldn't this be adjoint.(xs)...
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely, these calls should eventually become adjoint
/transpose
given recent discussion :). That said, with master as it stands, Adjoint
/Transpose
are correct, whereas I am not entirely confident that adjoint
/transpose
are correct and will remain correct through the few remaining pull requests in the #5332 series. After those remaining pull requests in the #5332 series, changing these calls to adjoint
/transpose
should become correct with certainty. Thoughts? :) Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as this is an intermediate state, I'm fine with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With a bit more thought, writing these methods in Adjoint
/Transpose
may also be ultimately best: The relevant objects are <:AbstractVector
, and as such Adjoint
/Transpose
-wrapping is correct, precise, and unambiguous (whereas adjoint
/transpose
will be more nebulous). Best!
Absent further commentary I plan to merge this change tomorrow morning PT or later. Best! |
Thanks all! :) |
Second take on #25219: This pull request implements the optimization @timholy suggested in #25083 (comment) (hence closes JuliaLang/LinearAlgebra.jl#492) and fixes the inference issue @martinholters caught in #25083 (comment). This version addresses the linalg/dense test failures discovered in #25219 as well, and adds a couple direct tests for that issue to linalg/adjtrans. Thanks and best!