-
Notifications
You must be signed in to change notification settings - Fork 43
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
Implement fallbacks for (un)whiten(!) and (inv)quad(!) to AbstractArray #162
Conversation
Co-authored-by: David Widmann <devmotion@users.noreply.github.com>
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.
Looks good to me in principle, but I would like to get someone else's opinion (@andreasnoack maybe?).
When commenting on the function signatures in the docstrings, I noticed that the general definitions for AbstractMatrix
could cause surprising slow-downs for AbstractPDMat
s with non-StridedArray
s if their specializations for (inv)quad!
etc. are only defined for StridedArray
s. So maybe it would be good to check if such restrictions still exist and if we can remove them.
src/generics.jl
Outdated
|
||
""" | ||
whiten(a::AbstractMatrix, x::AbstractVecOrMat) | ||
whiten(a::AbstractPDMat, x::StridedVecOrMat) |
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.
AbstractPDMat <: AbstractMatrix
, so maybe these signatures can be removed?
Co-authored-by: David Widmann <devmotion@users.noreply.github.com>
Codecov Report
@@ Coverage Diff @@
## master #162 +/- ##
==========================================
- Coverage 90.33% 90.19% -0.15%
==========================================
Files 8 8
Lines 414 418 +4
==========================================
+ Hits 374 377 +3
- Misses 40 41 +1
Continue to review full report at Codecov.
|
AFAIK those don't slow down. |
Co-authored-by: David Widmann <devmotion@users.noreply.github.com>
Are you sure? To me it seems e.g. that Line 113 in 92a5178
quad! for a::PDiagMat and x::StridedMatrix but by adding the generic fallback in this PR a call of e.g. quad!(r::AbstractArray, a::PDiagMat, x::SubArray{Float64,2}) will not use this specialized implementation but the less efficient fallback.
|
Looks fine to me: With this PR:julia> @which invquad!([2,2], PDiagMat([1,1]), [3 3; 3 3])
invquad!(r::AbstractArray, a::PDiagMat, x::StridedMatrix{T} where T) in PDMats at /home/oxinabox/JuliaEnvs/Distributions.jl/dev/PDMats/src/pdiagmat.jl:127
julia> @which invquad!([2,2], PDiagMat([1,1]), @view([3 3; 3 3][:,:]))
invquad!(r::AbstractArray, a::PDiagMat, x::StridedMatrix{T} where T) in PDMats at /home/oxinabox/JuliaEnvs/Distributions.jl/dev/PDMats/src/pdiagmat.jl:127
julia> @which invquad!([2,2], PDiagMat([1,1]), @view([3 3; 3 3][[2 4; 1 3]]))
invquad!(r::AbstractArray, a::AbstractMatrix, x::AbstractMatrix) in PDMats at /home/oxinabox/JuliaEnvs/Distributions.jl/dev/PDMats/src/generics.jl:140 Without this PR:julia> @which invquad!([2,2], PDiagMat([1,1]), [3 3; 3 3])
invquad!(r::AbstractArray, a::PDiagMat, x::StridedMatrix{T} where T) in PDMats at /home/oxinabox/.julia/packages/PDMats/pIpaj/src/pdiagmat.jl:127
julia> @which invquad!([2,2], PDiagMat([1,1]), @view([3 3; 3 3][:,:]))
invquad!(r::AbstractArray, a::PDiagMat, x::StridedMatrix{T} where T) in PDMats at /home/oxinabox/.julia/packages/PDMats/pIpaj/src/pdiagmat.jl:127
julia> @which invquad!([2,2], PDiagMat([1,1]), @view([3 3; 3 3][[2 4; 1 3]]))
ERROR: no unique matching method found for the specified argument types The only difference I see for this case is that the last one is now longer an error |
Yes, exactly, that's what I meant - it's not an error anymore but it uses the generic fallback instead of the method for diagonal matrices. |
ah right, there is a lot of code here that I think only works for StridedVectors, or rather code that only really works for things indexed by |
Given #163 is open, how do you feel about merging this? |
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.
Looks good to me, thanks!
Any additional comments or thoughts, @andreasnoack?
Any idea where the nightly tests error comes from?
|
Seems to be caused by the tests with BandedMatrices, so it might not be related to (or rather caused by) PDMats. |
The same test errors we've seen for a while on the master branch (eg https://github.com/JuliaStats/PDMats.jl/runs/6388016866?check_suite_focus=true), so it does not seem related to this PR. |
can this please be merged? |
done, thanks! |
This is the partner to JuliaStats/Distributions.jl#1552 (comment)
which will allow resolving JuliaStats/Distributions.jl#1219
It doesn't go and implement everything falling back to AbstractArray,
just the operations required for Multivariate Normals,
and their family (so I can test them)
In some cases that implementation is just making the PDMat one generic, (since
cholesky(x::PDMat)=x.chol
is defined, etc.