Hello.
On Tue, 21 Jun 2016 15:52:40 +0200, Eric Barnhill wrote:
On Tue, Jun 21, 2016 at 12:45 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
Mostly yes, but some utilities are used by packages that would
be good components (e.g. "o.a.c.m.distribution"). For example,
an efficient and robust root solver ("BrentSolver").
The analysis library is admirably integrated. For example, the
Solvers take
UnivariateFunctions for input, but so do the interpolators.
I agree. I have to, since I did some work there... ;-)
If we think that there are key commons-remit functions that require
use of
the analysis library "under the hood", than the whole thing should
probably
stay in.
IMO, the guide to "Does it belong in Commons?" should include rules of
thumbs like
* limited (even single) scope,
* stability, and
* usefulness beyond scientific applications and/or expert users.
Analysis is not an exotic or highly specialised library, so I don't
think
keeping it undermines the ability to set up an incubator/TLP with
more
specialised components.
No, it doesn't; but it think that the "o.a.c.m.analysis" package falls
short
of the above "rules" (as you pointed out yourself by citing the variety
of
interpolation routines).
Nevertheless, the single "BrentSolver" code could be copied (yes, I
know
that duplicate code is bad!) into a Commons "math-core" component so
that
we avoid a Commons component depending on the math TLP just because it
needs one root solver.
[The one case I had in mind is the "o.a.c.m.distribution" package. But
you may be right that it actually belongs to the TLP. If so, problem
solved.]
On the other hand, Analysis also transposes quite easily to the TLP
as a
self-contained unit.
o.a.c.m. complex.ComplexField, Quaternion, RootsOfUnity -> TLP
Not sure about "Quaternion"; could be in the "Complex" component.
Quaternion calls FastMath and Precision,
So does "Complex".
so if we are contemplating an
"alt-math" TLP component below, we have to consider how this impacts
commons-remit functions.
o.a.c.m. filter -> dormant
+0
There is an open issue:
https://issues.apache.org/jira/browse/MATH-932
Ah. Perhaps this person could be approached as to whether he wants to
maintain this component in a new TLP?
Sure.
>> o.a.c.m. stat.frequency -> perhaps belongs with random and
distribution?
o.a.c.m. stat.clustering -> dormant
o.a.c.m. stat.correlation -> array based methods to commons, Matrix
methods
to TLP
o.a.c.m. stat.descriptive, inferences, interval, ranking,
regression ->
Matrix methods to TLP. Array methods to commons. Statistics objects
should
be divided between both after a refactoring.
Not starting a discussion about this package...
[Basic flaws in the design were identified.]
I think we can agree, to get started, to leave the stats package as
it is
and keep it in commons, and worry about refactoring it later.
It is part of Commons Math as it was released in v3.6.1, based on the
"MATH_3_X" branch.
Until someone wants to tackle a refactoring and/or fix the identified
issues (cf. JIRA), it shouldn't be released again.
[Or only in a 3.6.x bug fix release.]
This POV also satisfy Patrick Meyer's requirement: it is _not_ dropped,
but won't become a standalone Commons component (unless someone wants
to
maintain it as such) or a module in the TLP (unless someone wants to
fix the identified issues).
So, in this hypothetical arrangement we're discussing, I think the
one
question is really whether the analysis package stays in commons
wholesale.
I'd favour it being part of the TLP for the reasons given above.
I have to say, I would be interested to help try to maintain it. I
would
learn a lot of useful math.
Hopefully, you can still do that in the TLP.
If there is an altmath TLP component with FastMath and Precision, do
BigReal and BigFraction go there also?
According to the "single scope" rule, I'd say that "fraction" should be
in its own component. [I'll shortly post my list of new component
candidates.]
Gilles
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
