On 08/05/2014 06:40 PM, Arne Schwarz wrote:
> No, but I am developing one with an extended Kalman filter where i
> will test various decompositions. I just stumbled over these lines
> because I read somewhere that explicit calculation of the inverse is
> not a thing one should do. And I suggested the Cholesky decomposition
> because it should be fast on these special matrices. But as I wanted
> to write an issue on this subject I saw an old resolved one where
> exactly the Cholesky decomposition was mentioned to be unsuitable
> because real world covariance matrices may not be perfectly symmetric.
> But it still may be better to use the QR decomposition directly
> without going over the inverse.
yes, due to floatingpoint arithmetic the resulting matrices may not be
perfectly symmetric, and this could lead to situations where no inverse
matrix could be calculated with the Cholesky decomposition.
This could be avoided by providing a userdefined epsilon value, but for
now we decided to use QR decomposition to compute the inverse matrix as
it is more robust.
> This is the code i wanted to suggest in the issue, on may want to
> replace "Cholesky" with "QR":
> // calculate gain matrix
> // K(k) = P(k) * H' * (H * P(k) * H' + R)^1
> // K(k) = P(k) * H' * S^1
> // K(k) * S = P(k) * H'
> // S' * K(k)' = H * P(k)'
> RealMatrix kalmanGain = new CholeskyDecomposition(s).getSolver().solve(
> errorCovariance.transpose().multiply(measurementMatrix)).transpose();
We need to evaluate this change with the test cases that previously
caused problems if it is robust enough or if QR decomposition should be
used instead.
Could you please open a new issue for this on JIRA so that we can keep
track of it?
Thanks,
Thomas

To unsubscribe, email: userunsubscribe@commons.apache.org
For additional commands, email: userhelp@commons.apache.org
