[
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¬itle=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
