commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <ericbarnh...@gmail.com>
Subject Re: [complex][math-util] dependencies
Date Wed, 30 Nov 2016 09:19:26 GMT
On Tue, Nov 29, 2016 at 8:48 PM, Gilles <gilles@harfang.homelinux.org>
wrote:

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

There is a ComplexField class. To keep my thoughts short, it looks like the
highly generic Field hierarchy does not have a place in C-M anymore and
should be dropped, including ComplexField.


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

Almost all of these are called in the various dependent classes. Given your
suggestions for getting rid of the dependent classes this should become
simple to fix.



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

Okay, this all ought to work.

Eric

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