-
-
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
Replace Val-types in cholesky[!] #41640
Conversation
@@ -132,7 +132,7 @@ end | |||
|
|||
#pivoted upper Cholesky | |||
if eltya != BigFloat | |||
cpapd = cholesky(apdh, Val(true)) | |||
cpapd = cholesky(apdh, RowMaximum()) |
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.
I'm wondering if we should maintain some tests that use cholesky(apdh, Val(true))
to ensure that the deprecations work and to avoid accidental breakage of later?
cpapd = cholesky(apdh, RowMaximum()) | |
cpapd = cholesky(apdh, RowMaximum()) |
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.
That makes the tests fail, see my first commit and its fix in the second.
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.
Also, we don't have that for lu
and qr
. Seeing the few "fix breakage" PRs in downstream packages made me feel bad about deprecating these functions, though there were no objections against that. Maybe we shouldn't officially deprecate them but only redirect them and list those functions in the deprecated.jl
list?
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.
Surprisingly, in my local build I don't even get a deprecation warning.
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.
That makes the tests fail
I see. So I guess CI runs with --depwarn=error
?
Surprisingly, in my local build I don't even get a deprecation warning.
Do you run with --depwarn=yes
?
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.
I just start the locally built Julia and then using LinearAlgebra; A = rand(3,3); A = A'A; cholesky(A, Val(true))
. So, I wasn't referring to the tests, just to "normal usage".
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.
Yeah but the default now is --depwarn=no
so users won't see these unless you set --depwarn=yes
on startup.
Just for the record: the changes in #40623 did break code elsewhere, e.g., JuliaArrays/StaticArrays.jl#931. I think the ambiguity errors there arose from changing certain AFAICT, there's no conversion of |
Sorry to hear that. I'll run tests this time. @nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
AFAICT, there are 3 packages affected: GLM, NiceNumbers and SciMLBase. I wonder what happens if we don't export the "old signature". For instance, this works: module MyTest
struct MyType end
export f
f(x, ::MyType) = 3x
@deprecate f(x, ::Val{false}=Val(false)) f(x, MyType()) false
end
using .MyTest
f(2, Val(false))
f(2, MyTest.MyType()) I wonder if that prevents ambiguity errors. |
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
This PR makes GLM.jl (for a reason that I don't understand) and NiceNumbers.jl (which would be easy to fix) fail, but not SciMLBase.jl (which had ambiguity issues initially) anymore. |
positive semi-definite matrix `A`. This is the return type of [`cholesky(_, Val(true))`](@ref), | ||
positive semi-definite matrix `A`. This is the return type of [`cholesky(_, ::RowMaximum)`](@ref), |
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.
The current cross reference doesn't work properly and links to the cholesky-docstring from SparseArrays.jl. Is this type-based reference better or how do I specify which docstring to link to? @fredrikekre
@dkarrasch MixedModels did get test breakage from the |
Hm, could be that it's better not to deprecate, but to redirect then? I wasn't sure about that, but nobody told me to not deprecate. OTOH, some people seem to like these type-based changes. So, how do we proceed with maximum benefit and least annoyance? |
Ultimately, deprecation is just re-direction with a warning and it would be good to be consistent with @static if VERSION < v"1.8.0-DEV.xxxx"
pivoted_cholesky(A; kwargs...) = cholesky(A, Val(true); kwargs...)
else
pivoted_cholesky(A; kwargs...) = cholesky(A, RowNorm(); kwargs...)
end and replace all the calls in that package as appropriate. Then those tests don't break, users aren't annoyed by deprecation warnings coming from package code, and inlining should prevent any performance hit. (If |
050dec8
to
d6eba05
Compare
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
@dkarrasch I think the GLM failure is the one mentioned above. |
I know, which is why GLM.jl already has a patch PR. 😉 |
How do we proceed here? There are three PRs in the pipeline to update failing packages (out of those that currently pass their test suite). Shall we merge now, update (if necessary) the specific |
@dkarrasch Cool, thanks. I'll review the GLM.jl PR as soon as this one here lands (so tag me as a reviewer when that happens). 😄 |
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. |
Extends #40623 to
cholesky
. Addresses #40623 (comment).