commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <ericbarnh...@gmail.com>
Subject Re: [MATH] what a commons-TLP split could look like
Date Mon, 20 Jun 2016 09:48:53 GMT
Like I said, my untrained eye. Sounds like it should definitely be kept.

Eric

On Mon, Jun 20, 2016 at 11:47 AM, sebb <sebbaz@gmail.com> wrote:

> On 20 June 2016 at 10:31, Eric Barnhill <ericbarnhill@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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