Hi.
On Mon, 20 Jun 2016 11:31:23 +0200, Eric Barnhill wrote:
Here's a proposed draft for how o.a.c.m might be split into a commons
component, and more sophisticated spin-out components, around which
we
might develop a new Math TLP or incubator project in which components
of
the project that find backers continue on, and those that do not are
frozen
at their current state for now but not discarded (henceforth I just
call
this TLP).
As a general strategy, I think it works to move the Field and Field
Element
superclasses into the TLP. Methods that use these elements or other
math-specific data classes (e.g. DerivativeStructure, Neuron,
AlternativeHypothesis) belong in the TLP. Array-based classes belong
in
commons. I see two exceptions to this. One is Complex objects which
seem to
me to belong in the commons remit. The other is the array of
statistics
objects (like Summary Statistics) as those statistics operations are
right
for commons. I think some refactoring of the stats packages may
enable a
clearer separation of the stats packages into those appropriate for
commons
and those appropriate for a TLP stats package, but I leave that for
another
thread.
Also I call a package "dormant" when to my untrained eye it appears
to have
been underdeveloped and should perhaps be put out of its misery.
Here is a list of usage count of CM packages (Github search[1]):
o.a.c.math3.analysis 2
o.a.c.math3.distribution 39
o.a.c.math3.exception 3
o.a.c.math3.linear 10
o.a.c.math3.primes 1
o.a.c.math3.random 25
o.a.c.math3.special 2
o.a.c.math3.stat 29
o.a.c.math3.util 25
[Does someone know how to make this list more representative by adding
data from other sources?]
Here we go:
--
o.a.c.m. Field, FieldElement, RealFieldElement -> TLP
+1
o.a.c.m. Analysis -> TLP
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").
o.a.c.m. complex.Complex, ComplexFormat, ComplexUtils -> commons
+1
o.a.c.m. complex.ComplexField, Quaternion, RootsOfUnity -> TLP
Not sure about "Quaternion"; could be in the "Complex" component.
o.a.c.m. dfp -> dormant
Not really (as Sebb pointed out already).
To be included in an "altmath" component together with "FastMath",
and other utilities for high precision testing.
o.a.c.m. exception -> commons
-1
Each component use its own exception set.
No hope to get a consensus on this subject. :-}
It would not be a good idea for a "core" package to have an exception
library as its sole dependency.
Also, for core packages, the exception machinery of CM is not
necessary.
[Personally, I don't think that it is ever necessary.]
o.a.c.m. filter -> dormant
+0
There is an open issue:
https://issues.apache.org/jira/browse/MATH-932
o.a.c.m. fraction -> all except Big FractionField to commons.
+1
BigFractionField to TLP
+1
o.a.c.m. genetics -> TLP
+1
But should be dropped there (IMO). See discussions on the ML and on
JIRA. [A few months ago, someone proposed to enhance it (as a GSOC
assignment).]
o.a.c.m. geometry -> TLP
+1
o.a.c.m. linear -> TLP
+1
o.a.c.m. ml -> TLP
+1
I thought it could be a component, but perhaps to sophisticated (?).
o.a.c.m. ode -> TLP
+1
o.a.c.m. optim and optimization -> combine into one TLP component
Just TLP.
[It's already a problem to get _one_ TLP. :-}]
o.a.c.m. random and distribution -> combine into one TLP component
"o.a.c.m.random" in 3.x is to be deprecated.
o.a.c.m.rng ("develop" branch) -> Commons component.
"o.a.c.m.random" in "develop" branch is WIP (TBD).
o.a.c.m.distribution -> Commons component (that depends on the "RNG"
component).
o.a.c.m. primes -> commons
+1
o.a.c.m. special -> dormant
A lot of work has been put into this (thanks to Sébastien Brisard) in
order to improve the accuracy.
It's used by several classes in "o.a.c.m.distribution"
Should be a Commons component
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.]
o.a.c.m.transform -> commons
+1
[Maybe, included in the "complex" component.]
o.a.c.m.util -> commons, perhaps refactored so the classes are in
more
informative package names
+1
But note that this was supposed to be an "internal" package.
In particular, utilities superseded by the JDK should be dropped.
Gilles
[1] Thanks to Christian Grobmeier for the hint.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
