@snaylor20 I was taking a brief look at your switching model code. Have you dealt with the case of different order models or types and mixing/converting the state vectors between the models? For example when switching from a CV model to CA, you need to add states, and conversely you need to drop states when going from CA to CV. It gets more complicated when switching from Coordinated Turn to CA or CV.
We have a similar issue in the IMM, GPB1 and GPB2 that we are looking at. We also have to handle the case of user adding their own motion models that we don't know about.
@sdhiscocks You could find LDL then make adjustments to the D matrix i.e. convert the zero elements to a small positive quantity, then create a new Cholesky decomp. Set , where . In this case it might make more sense to set the sqrt to a small number rather than take the sqrt of a small number.
I'm not sure how this would compare to what you doing now - it just keeps the main numerical part in the scipy library and just adds a bit of extra logic around it.
@sdhiscocks For the IMM, GPB1 etc. I need the user to supply conversion routines to convert to/from different state vector & covariance matrices. I think this has to be done at the transition model level. I was thinking of adding these functions as properties to the transition models. The conversion routines would be called as needed inside the IMMpredictor class as needed. If the user didn't define the functions, they would just default to a pre-defined function (identity transform).
I thought of providing a conversion function to the IMMpredictor class, but then I don't think we can distinguish between different types of models - for examples if a user creates multiple types of CombinedLinearGaussianTransitionModel - then we can't distinguish between these different models.
Are you ok with this design? Comments?