I second that, recalling some very rough API transitions/incompatibilities in
the past (e.g., around 'LeastSquaresOptimizer')...
--Wilhelm
--
View this message in context:
On Fri, 4 Nov 2016 03:16:29 -0700 (PDT), wilbur wrote:
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
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
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
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:
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
Hello.
It is "interesting" to see issue on such old codes...
What you propose looks sensible; the "linear" package has been known
for a long time to need an extensive redesign.
But I'm wondering about unforeseen side-effects of changing some of
those decisions without any possible feedback
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
On Sun, 30 Oct 2016 00:40:47 -0700 (PDT), wilbur wrote:
I am fine to submit a PR that reverts LUDecomposition to the standard
method
used in Jama.
Is that method better in all cases (w.r.t. performance _and_
accuracy)? [If there are trade-offs, it might be interesting
to provide both
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
Hi.
This conversation should preferably be continued on the
"dev" ML.
[CC'ing there.]
Best regards,
Gilles
On Sat, 29 Oct 2016 13:43:43 +0200, Eric Barnhill wrote:
Hi Wilbur,
That is strange that such a basic technique appears to be at odds
with best
practices, especially when said best
11 matches
Mail list logo
