commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <>
Subject Re: [MATH] what a commons-TLP split could look like
Date Tue, 21 Jun 2016 13:52:40 GMT
On Tue, Jun 21, 2016 at 12:45 AM, Gilles <>

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

The analysis library is admirably integrated. For example, the Solvers take
UnivariateFunctions for input, but so do the interpolators.

If we think that there are key commons-remit functions that require use of
the analysis library "under the hood", than the whole thing should probably
stay in.

Analysis is not an exotic or highly specialised library, so I don't think
keeping it undermines the ability to set up an incubator/TLP with more
specialised components.

On the other hand, Analysis also transposes quite easily to the TLP as a
self-contained unit.

o.a.c.m. complex.ComplexField, Quaternion, RootsOfUnity -> TLP
> Not sure about "Quaternion"; could be in the "Complex" component.

Quaternion calls FastMath and Precision, so if we are contemplating an
"alt-math" TLP component below, we have to consider how this impacts
commons-remit functions.

o.a.c.m. filter -> dormant
> +0
> There is an open issue:

Ah. Perhaps this person could be approached as to whether he wants to
maintain this component in a new TLP?

> 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.]

I think we can agree, to get started, to leave the stats package as it is
and keep it in commons, and worry about refactoring it later.

So, in this hypothetical arrangement we're discussing, I think the one
question is really whether the analysis package stays in commons wholesale.
I have to say, I would be interested to help try to maintain it. I would
learn a lot of useful math.

If there is an altmath TLP component with FastMath and Precision, do
BigReal and BigFraction go there also?


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