-
Notifications
You must be signed in to change notification settings - Fork 3
First Class Support for Rao-Blackwellisation #116
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
Open
THargreaves
wants to merge
20
commits into
main
Choose a base branch
from
th/first-class-rb
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SSMProblems.jl/SSMProblems documentation for PR #116 is available at: |
All existing unit tests now pass. |
SSMProblems.jl/GeneralisedFilters documentation for PR #116 is available at: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements the changes discussed in the attached proposal, which aims to offer first-class support for Rao-Blackwellisation. This involves abstracting elements of our codebase so that the RBPF is "nothing special" — if a feature (e.g. CSMC, AS, auxiliary weights, guided proposal) works for the regular PF, it should also work for the RBPF. This is motivated by the fact that they really are the same thing, with just some small changes to how we predict the particles and compute weights — p(y_t | x_t) becomes p(y_t | z_t, x_t).
This provides a concrete value proposition for our package that no other package provides, which will make it much easier to write our journal paper. I will get these changes finished within the next few days, and we can then look at package performance through use of StaticArrays as well as implementing some more advanced examples.
A few core changes to the interface were made to make this redesign feasible. These are:
a modification to the resampler to incorporate pre-weightsa wrapper for an existing filter (e.g.APF(RBPF(BF)))
). This was needed because the APF needs access to the model/inner filter to compute the lookahead weights, and the resample step doesn't have access to these.predict_particle
over all particles.predict_particle
dispatches on RB vs regular particle. This then callspropogate
which is a function that updates a state (particle with weight and ancestry). This doesn't change anything about the implementation, just gives us more opportunities to use dispatch to change behaviour.For ease of getting this PR implemented, I've made a few regressions. I've only done these if I could see a way of simply reimplementing them once it's clear this PR provides the full feature set it claims. These are:
predict
now only accepts the dynamics (rather than whole model), it's a bit more faffy to have a proposal that depends on the ObservationProcess. This isn't too big of a problem since you add a field in you Proposal struct to store the ObservationProcess (e.g. in the example script, I implement an optimal Gaussian proposal), but I appreciate this is more work for the user since they have to create a new proposal for each ObservationProcess they use.Likewise, there are a few things we can do in the future to tidy the code-base up a touch:
HierarchicalState
andRBState
types. Will make some of the dispatch more elegantA temporarily testing script is located atNew unit tests are now merged with the maintest/combination_test_script.jl
which tests all combinations of filter componentsruntests.jl
.Progress:
[ ] Implemented RB-ASGeneralisedFilters Distinguishing Features.pdf