Hey,
I would like to have a discussion on the design of mixture filters and
how to implement them (efficiently) in BFL.
In literature different mixture filters can be found: Gaussian sum
filters, Gaussian sum particle filters, Mixture Particle filters,...
The sequential filtering equations simplify (in most cases) to a set
of parallel filters which interact only through the calculation of the
mixture weights.
This results in a scheme like this
* Do systemUpdate for all parallel filters (keep the current mixture
weights)
* Do measUpdate for all parallel filters and adapt the mixture weights:
the new mixture weights = normalized weighted likelihood for the
component.
So again: the only part where the component filters interact is in the
calculation of the mixture weights.
Initially I planned to implement a mixtureFilter as a vector of
parallel Filters. In this case one should implement for every kind of
mixture filter the function which calculates the mixture weights (and
therefor the likelihood of the different components).
Now, I realized this would be quite inefficient since in a lot of
cases (e.g. mixture particle filter) the calculation of the mixture
weights would recompute a lot of things already computed in the
measUpdate for the individual components.
For instance in the mixture particle filter, the likelihood of the
component is the sum of the particle weights BEFORE normalization.
So maybe we could reuse some code!
Now, I think it can be usefull that the mixtureFilter can use some
functions of the parallel filters (also protected and private ones),
to make the compution more efficient (and reuse already implemented
methods,...) and certainly to avoid calculating something twice.
Now I consider to make the mixture filters (the specific
implementations, e.g. the mixture particle filter) a friend class of
the basic filter (e.g. the particle filter). This way the
mixtureFilter can use the private methods of the basic filters.
However, I would still have to add some methods, variables, ... such
that the mixtureFilter can easily get the information it wants.
Does this sounds like a good idea and why (not)?
Are there any other proposals?
Tinne
_______________________________________________
I hereby promise not to top-post on the
BFL mailing list
BFL [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/bfl
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
implementation of mixture filters
On Mon, Jan 26, 2009 at 3:39 PM, Tinne De Laet
<Tinne [dot] DeLaet [..] ...> wrote:
> I would like to have a discussion on the design of mixture filters and how
> to implement them (efficiently) in BFL.
>
> In literature different mixture filters can be found: Gaussian sum filters,
> Gaussian sum particle filters, Mixture Particle filters,...
> The sequential filtering equations simplify (in most cases) to a set of
> parallel filters which interact only through the calculation of the mixture
> weights.
> This results in a scheme like this
>
> * Do systemUpdate for all parallel filters (keep the current mixture
> weights)
> * Do measUpdate for all parallel filters and adapt the mixture weights:
> the new mixture weights = normalized weighted likelihood for the component.
>
> So again: the only part where the component filters interact is in the
> calculation of the mixture weights.
>
> Initially I planned to implement a mixtureFilter as a vector of parallel
> Filters. In this case one should implement for every kind of mixture filter
> the function which calculates the mixture weights (and therefor the
> likelihood of the different components).
> Now, I realized this would be quite inefficient since in a lot of cases
> (e.g. mixture particle filter) the calculation of the mixture weights would
> recompute a lot of things already computed in the measUpdate for the
> individual components.
> For instance in the mixture particle filter, the likelihood of the component
> is the sum of the particle weights BEFORE normalization.
> So maybe we could reuse some code!
>
> Now, I think it can be usefull that the mixtureFilter can use some functions
> of the parallel filters (also protected and private ones), to make the
> compution more efficient (and reuse already implemented methods,...) and
> certainly to avoid calculating something twice.
> Now I consider to make the mixture filters (the specific implementations,
> e.g. the mixture particle filter) a friend class of the basic filter (e.g.
> the particle filter). This way the mixtureFilter can use the private methods
> of the basic filters.
> However, I would still have to add some methods, variables, ... such that
> the mixtureFilter can easily get the information it wants.
>
> Does this sounds like a good idea and why (not)?
Can you show a class diagram (or st alike) which shows where you would
fit in the mixtureFilter class(es)? Because I think the "best"
solution depends on how you see this.
Klaas
_______________________________________________
I hereby promise not to top-post on the
BFL mailing list
BFL [..] ...
http://lists.mech.kuleuven.be/mailman/listinfo/bfl
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
implementation of mixture filters
...
>
> Can you show a class diagram (or st alike) which shows where you would
> fit in the mixtureFilter class(es)? Because I think the "best"
> solution depends on how you see this.
See attached diagram
MixtureFilter would directly inherit from Filter.
MixtureFilter would have a mixture as prior and post pdf.
Some subclasses of mixtureFilter could be implemented as a set of parallel
baseFilters: for instance MixturePF could contain a vector of PF's.
Let's go on with the MixturePF:
To update the posterior of MixturePF, update can be called to each PF
seperately and then the weights of the mixture have to be adapted. To
calculate the weights, a lot of the computation done in the update of the
basis particle filters have to be done again.
I'm looking for a procedure to minimize the amount of copy-pasted code.
Tinne
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm