Hello.

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
  https://issues.apache.org/jira/browse/MATH-1049
  https://issues.apache.org/jira/browse/MATH-1024

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

Regards,
Gilles


--Wilhelm



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to