commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <>
Subject [MATH] what a commons-TLP split could look like
Date Mon, 20 Jun 2016 09:31:23 GMT
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

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 we go:
o.a.c.m. Field, FieldElement, RealFieldElement -> TLP
o.a.c.m. Analysis -> TLP
o.a.c.m. complex.Complex, ComplexFormat, ComplexUtils -> commons
o.a.c.m. complex.ComplexField, Quaternion, RootsOfUnity -> TLP
o.a.c.m. dfp -> dormant
o.a.c.m. exception -> commons
o.a.c.m. filter -> dormant
o.a.c.m. fraction -> all except Big FractionField to commons.
BigFractionField to TLP
o.a.c.m. genetics -> TLP
o.a.c.m. geometry -> TLP
o.a.c.m. linear -> TLP
o.a.c.m. ml -> TLP
o.a.c.m. ode -> TLP
o.a.c.m. optim and optimization -> combine into one TLP component
o.a.c.m. random and distribution -> combine into one TLP component
o.a.c.m. primes -> commons
o.a.c.m. special -> dormant
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.
o.a.c.m.transform -> commons
o.a.c.m.util -> commons, perhaps refactored so the classes are in more
informative package names


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message