[jira] [Issue Comment Edited] (MATH-485) Feature Request: Kalman Filter

["Thomas Neidhart (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MATH-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021142#comment-13021142 ] 

Thomas Neidhart edited comment on MATH-485 at 4/19/11 8:57 AM:
---------------------------------------------------------------

Thanks for the comments!

@1 & 2: I do not know about a general decision if algo classes should be serializable, but I thought it makes sense in this case. The serialization method was derived from SimplexTableau and the corresponding description in MathUtils. As the different matrix object can also be set from external, they may not all be Array2DRowRealMatrix, but I do not know if this makes a difference for the serialization.

@3: ack, the member variables have been adjusted already, but the constructor has to be cleaned up

@4: the constant voltage example (from the paper of Welch & Bishop) is the basis for the test case, but I was really unsure which reasonable test criteria to use for algorithm validation. The very naive approach I currently use is to basically test if the estimated state has less diff to the real value than the artificially imposed measurement/process noise and whether the error covariance converges to some value (although this is not complete yet).

After some reflection, maybe it makes more sense to split the internal data of the Kalman filter into two parts:

 - elements that model the process to be estimated (transition matrix, measurement matrix, control matrix, initial state)
 - elements that define how the filter tries to estimate the state (mainly the noise covariance matrizen)

The constructor would then look something like this:

  KalmanFilter(FilterProcessModel model, RealMatrix measurementNoiseCov, RealMatrix processNoiseCov)

The FilterProcessModel would be serializable, while the KalmanFilter is not.

      was (Author: tn):
    Thanks for the comments!

@1 & 2: I do not know about a general decision if algo classes should be serializable, but I thought it makes sense in this case. The serialization method was derived from SimplexTableau and the corresponding description in MathUtils. As the different matrix object can also be set from external, they may not all be Array2DRowRealMatrix, but I do not know if this makes a difference for the serialization.

@3: ack, the member variables have been adjusted already, but the constructor has to be cleaned up

@4: the constant voltage example (from the paper of Welch & Bishop) is the basis for the test case, but I was really unsure which reasonable test criteria to use for algorithm validation. The very naive approach I currently use is to basically test if the estimated state has less diff to the real value than the artificially imposed measurement/process noise and whether the error covariance converges to some value (although this is not complete yet).
  
> Feature Request: Kalman Filter
> ------------------------------
>
>                 Key: MATH-485
>                 URL: https://issues.apache.org/jira/browse/MATH-485
>             Project: Commons Math
>          Issue Type: Wish
>            Reporter: Benjamin McCann
>             Fix For: 3.0
>
>         Attachments: KalmanFilterExample.java, MATH-485.patch
>
>
> I'd love it if Commons Math could add support for the Kalman filter.  Here are a few implementations that might be able to be used for reference or included if they're using compatible licenses:
> http://code.google.com/p/efficient-java-matrix-library/wiki/KalmanFilterExamples
> http://mathstat.asu.edu/~eubank/
> http://www.fit.vutbr.cz/research/prod/index.php.en?id=53&notitle=1
> http://sourceforge.net/projects/jkalman/
> http://www.vni.com/products/imsl/jmsl/v30/api/com/imsl/stat/KalmanFilterEx1.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira