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
