Hi Gilles, thanks for pointing me to the JIRA system - will try to do my best ;-)
I am aware of the potential of breaking existing code with any such changes. However, expected problems seem to be minor in this case. Also, if existing code relies on such obvious design flaws it should be fixed as well. In particular: 1) If a 'null' result from getL(), getU() or getP() was sofar used to determine the singularity of the input matrix, the isNonSingular() method should have been called instead. Of course, this behaviour could still be preserved if needed. 2) If, for some reason, getL(), getU() or getP() were called repeatedly -- relying on the fact that they always return a reference to the SAME matrix -- this is dangerous practice and should be stopped. If needed, just bind the result from the first call to some variable. 3) Making the inner 'Solver' class non-static should have no consequences for expernal code. I also found some literal '(x == 0.0)' tests which should not be used in numerical code (something we teach our students in the first semester). At this moment I do not see the need for a new package. If a more extensive redesign is wanted, I suggest to use interfaces at the top level to allow for different concrete implementations. The same likely applies to other decompositions. --Wilhelm -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-Math-Re-LU-decomposition-very-SLOW-commons-math3-linear-tp4692297p4692376.html Sent from the Commons - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
