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