Hello Eric.
On Tue, 29 Nov 2016 14:19:54 +0100, Eric Barnhill wrote:
I thought it would be good to raise a structural question here rather
than
in the commons-complex JIRA.
The Complex library has multiple dependencies on three packages:
-- commons-math base classes (e.g. Field et al.)
Do you foresee any application for "Field" or "FieldElement" classes
in this component?
If not, just drop them.
-- commons-math exceptions
In "Commons RNG", I completely dropped all custom-made exceptions.
I suggest you do the same here.
IMO, "simple", low-level, components can do with just throwing
runtime exceptions from the standard library (with a hard-coded
_English_ message).
-- commons-math util (numerous classes)
My suggestions:
* CompositeFormat: drop
* FastMath: replace with JDK's "Math" calls[1]
* IntegerSequence: use a _private_ copy[2][3]
* MathUtils:
- drop "checkNotNull"[4]
- drop "equals(double,double)", "hash(double)" and
"hash(double[])"[5]
* Precision: extract the needed bits and make a private copy.
[1] Until we set out to make them interchangeable at runtime.
[2] Until we agree on creating a component for _very_ low-level
utilities, and on its contents.
[3] Like I did with classes "InternalUtils" and "InternalGamma"
in the "sampling" module of "Commons RNG".
[4] Let the JVM do it.
[5] They are trivial; use methods from the JDK directly.
Otherwise it is self-contained. (Some tests within the
QuaternionTest
class use a large chain of dependencies from the geometry package, so
I
think it is best to simply remove the geometry-dependent tests until
someone arrives to maintain that library.)
Better keep the tests, and make "Commons Math" (v3.6.1) a
dependency with scope "test" (as I did for module "sampling"
in "Commons RNG").
This suggests to me that, if we were to continue with some kind of
math-utils base class, it should consist of these three current
packages:
the base classes, util and exception.
Probably best to start from requirements, rather than previous design.
As per the above, this discussion can be postponed.
It might in fact make sense to spin
out this base library first (which I am happy to oversee) then return
to
finishing out the independent complex library with only
commons-math-util
as dependency.
That's not going to work here. [Been there, done that.]
Better create something directly useful (to you and others) and
as a building block for "SigProc".
Once there are "clients", it will be time to refactor a "base"
component from the "private" parts of "Commons Complex".
Would this also be compatible with the current trajectory of
RNG?
I don't understand the question.
Best,
Gilles
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
