commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From wilbur <wil...@ieee.org>
Subject Re: [Math] Re: LU decomposition very SLOW (commons.math3.linear)
Date Wed, 02 Nov 2016 12:32:50 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message