I second that, recalling some very rough API transitions/incompatibilities in
the past (e.g., around 'LeastSquaresOptimizer')...
--Wilhelm
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/Re-Math-Re-LU-decomposition-very-SLOW-commons-math3-linear-tp4692297p4692482.ht
Makes all sense. I will prepare a "minimally invasive" patch that exactly
mimics the original behavior.
In a possible future version, I think interfaces should be used from the
beginning, even if there is only a small chance that different
implementations arise. It is hard/impossible to resolve th
Hi, I successully managed to post an issue on JIRA
(https://issues.apache.org/jira/browse/MATH-1390) and I am willing to fix
it. How does this issue get assigned? -- anything else I need to do? Sorry
for my ignorance ...
--Wilhelm
--
View this message in context:
http://apache-commons.680414.n4
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
OK, I built 'LUDecomposition' back to match the original Jama version and
fixed a few things on the way. Performance is consistently much better and I
did not notice any differences in numerical accuracy. While this appears to
be the same algorithm, I have not figured out why (though I can see WHER
I am fine to submit a PR that reverts LUDecomposition to the standard method
used in Jama.
--Wilhelm
--
View this message in context:
http://apache-commons.680414.n4.nabble.com/Re-Math-Re-LU-decomposition-very-SLOW-commons-math3-linear-tp4692297p4692305.html
Sent from the Commons - Dev mailin
