commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wilbur <>
Subject Re: [Math] Re: LU decomposition very SLOW (commons.math3.linear)
Date Mon, 31 Oct 2016 09:16:15 GMT
OK, I built 'LUDecomposition' back to match the original Jama version and
fixed a few things on the way. Performance is consistently much better and I
did not notice any differences in numerical accuracy. While this appears to
be the same algorithm, I have not figured out why (though I can see WHERE)
the current CM implementation wastes so much time.

Working myself through the code I ran into two other issues that should be
fixed but will change the behavior of this class:

1) The decomposition algorithm works fine even if the input matrix A is
singular. However, the current implementation exits the constructor as soon
as singularity is detected and the methods getL(), getU(), and getP() return
null. I propose to let the decomposition complete even for singular matrices
and always return a valid decomposition. As usual, the returned
'DecompositionSolver' will raise an exception when solve() is invoked on a
singular matrix.

2) In the current implementation, the methods getL(), getU(), and getP()
return references to the SAME (cached) matrix objects in successive calls.
This appears to be unjustified and bad programming practice, since
RealMatrix objects are mutable. For some reason, though, this is considered
an important feature, since it is explicitly tested for in the JUnit test. I
propose to cache the corresponding primitive arrays and return a new matrix
instance in every call (modified the JUnit test).

Also, I see no reason to make the inner class 'Solver' *static*, since such
an object cannot exist without the associated LUDecomposition itself. I this
changed this to a non-static inner class. (Same strange pattern is used in
QRDecomposition and probably elsewhere.)

My proposed re-implementation can be found  here
and the associated JUnit tests  here


TODO: The class 'FieldLUDecomposition' does the same but on a different
matrix type -- needs to be reworked as well (possibly avoiding code

Anyone please let me know in case of any objections or possible


PS: Being new to this list I am not sure how to properly create issues,
since they are not open on GitHub.

View this message in context:
Sent from the Commons - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message