ParticleFilters.jl icon indicating copy to clipboard operation
ParticleFilters.jl copied to clipboard

Belief constructors

Open zsunberg opened this issue 6 years ago • 3 comments

It might be nice to have some constructors for the beliefs to answer questions like "how do I make a particle belief from a SparseCat". But, it's not 100% clear which way to do this.

Approach 1:

ParticleCollection(d, n::Integer; rng=Base.GLOBAL_RNG) = ParticleCollection([rand(rng, d) for i in 1:n])

(and similar for WeightedParticleBelief)

Approach 2:

function WeightedParticleBelief(d)
    pairs = collect(weighted_iterator(d))
    return WeightedParticleBelief([first(p) for p in pairs], [last(p) for p in pairs])
end

and a similar ParticleCollection(d, n::Integer=100) that allocates unweighted particles in proportion to their weight.


Approach 2 is nice because it's deterministic and low variance, but it won't work for some distributions (e.g. continuous ones).

zsunberg avatar May 25 '18 00:05 zsunberg

I have a slight preference for Approach 1 to consider continuous distributions. It may also be valuable to have a constructor in the other direction, e.g. ParticleCollection -> SparseCat using the pdf fcn for all states. In the previously deprecated ParticleBelief, there was a probs_dict that was essentially a SparseCat.

sharonzhou avatar May 25 '18 06:05 sharonzhou

Approach 1 seems more straightforward to me and more generic (apply to any distributions). I don't see how you control the number of particles in Approach 2? As you said, the fact that 2 is deterministic and low variance might be appealing, maybe it should be specific to converting SparseCat distribtions only?

MaximeBouton avatar May 25 '18 09:05 MaximeBouton

Yeah, SparseCat from ParticleCollection should be straightforward - we still have that probs_dict as _probs.

I don't see how you control the number of particles in Approach 2?

In the WeightedParticleBelief there is just one particle for each unique state

As you said, the fact that 2 is deterministic and low variance might be appealing, maybe it should be specific to converting SparseCat distribtions only?

I don't think it's a good idea to have the constructor do qualitatively different things based on the input type. That will just lead to confusion.

Probably the best way is to just use Approach 1 for the constructor, and then have another function called exact_particle_belief that does Approach 2.

zsunberg avatar May 28 '18 23:05 zsunberg