Like I said, my untrained eye. Sounds like it should definitely be kept. Eric
On Mon, Jun 20, 2016 at 11:47 AM, sebb <seb...@gmail.com> wrote: > On 20 June 2016 at 10:31, Eric Barnhill <ericbarnh...@gmail.com> 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 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 > > That does not seem right. > > This is needed for FastMath testing > > AFAICT, there are no unresolved bug reports relating to dfp; and those > that were raised were dealt with in a reasonable time frame. > > So why drop it? > > > 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 > > -- > > > > Eric > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
