-
Notifications
You must be signed in to change notification settings - Fork 17
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
Substitute types with abstractions #132
Conversation
b104811
to
72ed703
Compare
TODO: add tests with different covariance matrix types |
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.
Hi Tom - This looks great! I only had a couple of very small comments.
Beside these I should point out that:
- I definitely like the removal of decomposition wrapper
- I like the VecOrMat types to deal with reshaping issues
- I like the mutability of MCMC (finally we can remove the
[1]
array changes)
Just a small point in the SVD
LGTM! Merge away |
b47ba89
to
cbaf482
Compare
Update: 5d9def7 is a rebase & squash of commits made up to @odunbar's approval. Extra commits should be non-controversial:
|
bors try |
tryBuild failed: |
bors try |
tryBuild succeeded: |
Implements abstract typing done in EnsembleKalmanProcesses.jl#100. Adds support & tests for covariance as a dense matrix, Diagonal or UniformScaling type. Use abstract types in Emulator Combine logic for GaussianProcess predict() Use abstract types in GaussianProcess Use abstract types in MarkovChainMonteCarlo Add UniformScaling as a covariance type Correct SVD transformation Qualify use of GaussianProcesses.GPE, for clarity Fix DataContainers import Make MCMC struct mutable (to be reverted in PR #130) Methods & tests for Diagonal, UniformScaling cov types
cbaf482
to
9e69409
Compare
bors r+ |
Build succeeded: |
This PR implements the abstract typing done in CliMA/EnsembleKalmanProcesses.jl#100, e.g.
Array{FT, 2}
→AbstractMatrix{FT}
, in order to be consistent with that dependency.See the discussion concerning performance at that PR; use of abstract types is recommended against for perf reasons, but the rationale here is that the code is essentially "glue" rather than numerical routines appearing in hot loops, so writing for generality over perf is justified.
Another downside is that existing abstract types aren't "abstract" enough, e.g.
UniformScaling
is not a subtype ofAbstractMatrix
and must be handled separately.As a benefit, the changes made here result in some method signatures being more strongly typed than they are in
master
, allowing us to replace repeated code with multiple dispatch ("Don't Repeat Yourself").MCMC
is changed to a mutable struct, instead of continuing the current code's practice of enabling mutability by making fields of the struct 1x1 Arrays instead of scalars. This change is a moot point, however, since it will be overridden by PR #130.