After reading more about the proposed changes, I am now comfortable with dividing the library into separate components. However, I have two concerns. First, a package or class that passes unit tests should not be abandoned or depricated just because there is no one to support it. It should only be dropped if it fails a test AND there is no one to support it. Second, we should be careful about dividing the library into too many parts. For example, I don't agree with separating array based stats from matrix or online based stats. That's my two cents. Thanks. On Jun 20, 2016 5:31 AM, "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 > 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 >
