commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [MATH] what a commons-TLP split could look like
Date Mon, 20 Jun 2016 22:45:11 GMT

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


> 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


> 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

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 
[Personally, I don't think that it is ever necessary.]

> o.a.c.m. filter -> dormant

There is an open issue:

> o.a.c.m. fraction -> all except Big FractionField to commons.


> BigFractionField to TLP


> o.a.c.m. genetics -> TLP

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

> o.a.c.m. geometry -> TLP


> o.a.c.m. linear -> TLP


> o.a.c.m. ml -> TLP

I thought it could be a component, but perhaps to sophisticated (?).

> o.a.c.m. ode -> TLP


> 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"

> o.a.c.m. primes -> commons


> 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

[Maybe, included in the "complex" component.]

> o.a.c.m.util -> commons, perhaps refactored so the classes are in 
> more
> informative package names


But note that this was supposed to be an "internal" package.
In particular, utilities superseded by the JDK should be dropped.


[1] Thanks to Christian Grobmeier for the hint.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message