commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Re: LU decomposition very SLOW (commons.math3.linear)
Date Fri, 04 Nov 2016 00:02:37 GMT

On Wed, 2 Nov 2016 05:32:50 -0700 (PDT), wilbur wrote:
> 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.

It should probably be changed only as part of more thorough review
of all the decomposition classes.
See also

> 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.

It might have been assumed that in the majority of cases, there are
no "repeated" calls.
In this case, the extra copy is a performance loss, especially when
the matrix is large.

> 3) Making the inner 'Solver' class non-static should have no 
> consequences
> for expernal code.

It looks so indeed.

> 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).

Some of them may be on purpose.
Check the "findbugs-exclude-filter.xml" file.

> At this moment I do not see the need for a new package. If a more 
> extensive
> redesign is wanted,

Along the years, a major overhaul of the "linear" has been
discussed many times... [Cf. ML archive.]

> I suggest to use interfaces at the top level to allow
> for different concrete implementations. The same likely applies to 
> other
> decompositions.

Ideally, I agree, but unless several implementations are
actually foreseen, it might not be worth it...


> --Wilhelm

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

View raw message