Redesign base particle filter class.

[jmbarr]

Decision needs to be made regarding the particle filter construction

Currently: Particle types contain a state_vector and weight (and parent). These are wrapped in a ParticleState which is just a list. Particle predictors and updaters work by operating the (transition, measurement) functions on these state_vectors. This won’t work with transition/measurement functions that take State, rather than StateVector types.

This might be changed in either of two ways. Probably the easiest is to adjust Particle so as to take a State rather than StateVector. The problem with that is going to be a large amount of redundant logic. If the State contains stuff external to the state_vector (metadata, transformation functions, etc) that will be replicated needlessly for each particle in the ParticleState

Better would be to construct a ParticleState which is more than a list. Instead it’s an analogue of a base state which it “particlizes”, preserving the metadata and functions and merely replicating the state vector N times. It would carry functions which calculate weighted mean and covariance of particles.

Would affect/address #130 and #26.

[sdhiscocks]

So are you thinking that ParticleState contains a list of state vectors, and weights. And then have a property/method that generates a list/iterable of "Particle", each of which is a subclass of State, copying ParticleStates metadata, timestamps, etc.?

[jmbarr]

are you thinking that ParticleState contains a list of state vectors, and weights..

Yes, I think that's a basic description of what a particle state is.

then have a property/method that generates a list/iterable of "Particle",

Not sure this part is best. Particle is currently just an object which holds state_vector and weight. Making it a subclass of State allows the models to work unmodified after #155 but presumably introduces a lot of bloat as you replicate and process a State for each and every state_vector.

More efficient I think would be adapting the sensor and transition models to understand how to deal with a ParticleState. They then wouldn't need to copy "static" parameters every time an operation is undertaken.

It might be as simple as telling models to expect a list of state_vectors and to return their operation on each member of that list. If we set State with a default state_vector as a list of one item and a default weight of 1, we might not need to define ParticleState with any additional logic. ?

[jmbarr]

In any case ParticleState should inherit from State. It doesn't currently.

[sjenkins20]

We have incorporated some extra information into each particle. Our multi model version of the StoneSoup particle filter requires an additional attribute in the Particle class called dynamic_model. This is an integer representing the transition model used to generate the current state within the particle.

Additionally, we have implemented a Rao-Blackwellised algorithm for tracking and classification. Particles here possess a vector of probabilities requiring that the particle class have another attribute called rao_probabilities. The vector of probabilities represents the probability of each model producing the current state within the particle. There is the possibility that along with this, we many need to record the model number that generated that particle state too.

An additional application which is currently being worked on outside of Stone Soup, is the fixed-lag SMC algorithm. The aim is to incorporate this algorithm into Stone Soup in the future. Each particle stores a path of states over time, together with a path of model numbers that represent the models used to generate the states. The period of time stored in the particle is variable. There is still only one weight associated with the particle, but the weight represents the probability of the entire path of states over time. In Matlab or Python we would store the path in each particle as a matrix.

[jmbarr]

A bit belatedly, I'm convening a 'Particle Conference'. If you (or you think others) should participate, please assign yourself (or assign those others*) to this issue.

I assume this will take the form of some sort of video conference/web teaming effort. As there's inevitably some divergence in what each of our systems and networks can cope with, could you please let me have any preferences and restrictions regarding which tools to use. Also, if anyone has any bright ideas, please do pipe up. I, for one, would like some sort of joint whiteboard facility, but don't have any experience of such.

Once that's done I'll send round some prospective times/dates and then whatever meeting invites are appropriate.

*if it turns out you can't do the assignment, just let me know and I can grab them.

[jmbarr]

Despite appearances, I've not entirely neglected this topic.

Thoughts:

1. Adjust the current ParticleState such that the [Particle] list is replaced by a 2d StateVector where individual samples are columns of this matrix. Problem is that StateVector is currently constrained to be nx1. Options are (a) loosen the restriction on StateVector, (b) create a ParticleStateVector class or (c) use np.array

2. I imagine the ParticlePredictor would be a fairly direct analogue of the xKalmanPredictors to generate $p(x_k|x_{{k-1})$ from $p(x_k)$.

3. ParticleUpdater will update the weights based on input prediction. Most sensibly this would be accomplished via Importance Sampling which would require a prediction ($p(x_k|x_{{k-1})$), a measurement likelihood $p(z_k|x_k)$ and a proposal distribution $\pi(x_k|x_{0:k-1}, z_{0:k})$, selectable by the user. A question we might want to consider is if we generate an abstract ParticleUpdater class from which will derive a SequentialImportanceSamplingUpdater (SISUpdater) in order to allow versions of the particle filter which don't do importance sampling.

4. In any practical implementation we'll be doing resampling. But I think it should remain optional and tuneable. This might be best accomplished by way of a new Sampler or Resampler class. I guess a Sampler would take a distribution as input and then return a requested number of points from that distribution. Methods for doing this exist in numpy via various .rvs() methods. So simple samplers might just be wrappers for this. We should allow for the possibility of more sophisticated ones though. The Resampler class would be distinct but related in that its objective is to take a set of samples and return a new set of samples with less sample impoverishment. Samplers might be useful all over the place.

[sdhiscocks]

1. Adjust the current ParticleState such that the [Particle] list is replaced by a 2d StateVector where individual samples are columns of this matrix. Problem is that StateVector is currently constrained to be nx1. Options are (a) loosen the restriction on StateVector, (b) create a ParticleStateVector class or (c) use np.array

I've been looking at creating a StateVectors class to solve a problem (which actually came from Particle Filter, but actually wider issue). I'll aim to share what I've done soon.

[sdhiscocks]

I think we can close this now, as some points covered by #365 and #132 (includes change to make resampling optional). Suggest we open new issue(s) for any outstanding issues.