search

TuringLang / GeneralisedFilters.jl

Filtering and smoothing algorithms for state space models with analytic (or approximately/partially analytic) solutions
MIT License
0 stars 0 forks source link

Migrating Generalised Filters #7

Closed charlesknipp closed 4 days ago

charlesknipp commented 2 weeks ago

After my discussion with @THargreaves, I decided to port my existing interface to what is now AnalyticalFilters.jl. Every algorithm now fits into a modified version of my general structure proposed in https://github.com/TuringLang/SSMProblems.jl/pull/56 without minimal alterations to the intended functionality. Hopefully this serves as a step in the right direction to address #6 but I will leave that to the reviewers.

With that being said, since the original algorithms weren't designed with this structure in mind, their ports are not necessarily feature rich. For example, Rao-Blackwellized filters have yet to support ParticleContainers, and still rely on rb_eltype to preallocate intermediate states. I also have yet to touch the other branches (notable GPU filters, HMM integration, and the KalmanFilters.jl wrapper), which I'm undecided to include in this PR.

Note that this version relies on my branch of SSMProblems with better type signatures and controls defined in kwargs.

Lastly, feel free to light this up with commits, any design choice alterations are seriously welcome.

THargreaves commented 1 week ago

Fantastic stuff! Thank you for making these (some of which I assume were quite tedious) changes.

I'm happy to take a look at the RBPF and see if I can rewrite to match the predict/update setup and incorporate the particle storage.

I'll make a few other tweaks too. Think they'll be fairly uncontroversial but anyone feel free to comment if you're unsure about them.

I agree for the simplicity of the PR, we can get this stuff merged first and then I can convert the wrappers/GPU code to this interface.

charlesknipp commented 1 week ago

Fantastic stuff! Thank you for making these (some of which I assume were quite tedious) changes.

Eh it was nothing too terrible. Most algorithms were designed with this structure in mind, so it really wasn't too bad.

I'm happy to take a look at the RBPF and see if I can rewrite to match the predict/update setup and incorporate the particle storage.

This would be stellar. I admittedly didn't spend too much time trying to rewrite any of the current functions. Although I did think of a way to perhaps get rid of rb_eltype by using map to allocate a vector of particles, similar to how the bootstrap filter behaves.

THargreaves commented 6 days ago

RBPF is now feature rich with resampling, (sparse) particle storage, and new interface.

Still some small issues to think about (e.g. rb_eltype) but I think we're probably at a good point to merge this PR and make further issues/PR for those.

THargreaves commented 5 days ago

I also wonder if the new separation into predict and update adds any cost via additional indexing. If the difference is noticeable, I have no problem going back to step in this case.

Hmm possibly. Will have to have a look into this, but I already planned on having joint update-predict steps for the square-root KF (you can halve number of QR decomps if you don't compute proposal distributions) so not too bad to have a one-step alternative for this too.

THargreaves commented 5 days ago

If no objections, I'll do some minor house-keeping changes and include Frederic's suggestions and then merge this afternoon.