Handling model orders in mixture models

[DaveKirkland]

I've based this on Lyudmils IMM branch. This code handles the different order models. I've included some examples in the example directory. The user has a fair bit to manage to get it right. The list of models provided to the IMMupdater and IMMpredictor need to coincide.

I've also coded to routines to do the state conversions cv2ca and ca2cv. These are provided to the Updater and Predictor - these handle the conversion of the state predictions, measurement predictions and the state updates. They need to work with a number of different types GaussianState, GaussianMeasurementPrediction, WeightedGaussianState, and a few others. The same routines are passed to the Predictor and Updator - You could use break each function (cv2ca(), ca2vs() ) into 2 separate functions and pass them to the Predictor and Updater respectively. Since the code is very similar I just keep it simple. It's really up to whomever is coding these routines to do it properly.

I'm not looking to merge this into the master just yet, but I'd like to get some feedback on the design.

The IMMPredictor/IMMUpdater is calling the conversion routines explicitly right now - so that part would need to be duplicated in the other mixture model code. I don't really like it this way - it is very easy to get wrong. A better way is to used a decorator on the predict() and update() functions. Trying to add a decorator around the predict() and update() abstractmethods in the base class doesn't work - they don't get called. I can put them explicitly around the methods in the KalmanPredictor and KalmanUpdater classes and that does work.

One last item - the current method just uses zero padding for the larger state vectors and covariance matrices. As David Crouse pointed out, this is not optimal. If you want to fill in the states/covariances with extra information - we need to incorporate a way to pass that information to the routines like cv2ca() and ca2cv().

[DaveKirkland]

I've updated the implementation. We now create a new class for the predictors/updaters to be used in the IMM predictor/updater. This keeps the code inside the IMM very clean.

Some TBD:

• If called multiple times with the same class type, this will create a new class every time.
• I put the new class in the predictor directory for now. This should probably be put somewhere else.