commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math][Numbers] Move Field, etc. to numbers?
Date Fri, 22 Dec 2017 15:42:37 GMT

Sorry for not replying earlier (and the top-post).

I've a bad feeling about "Field" and "FieldElement" as
they exist in "Commons Math".
I'd like to see whether/how we can do better starting
from "scratch"[1].

I started to make changes in the CM codes but more and
more were necessary because "Field" is used (often
indirectly, when a type "implements" it) in hundreds
of statements...

In "Commons Numbers", a worthy goal is to not tangle
"field"-related classes with a basic utility such as

So, I'd wish to create a new module:
with new classes such as "FractionField" that reflect
the intended functionality[1].


If that makes sense, then CM ("client" code) should
_adapt_ to the lower level API rather then the other
way around (in CM, the higher level concepts, such as
"FieldMatrix" impose a complex API on otherwise basic



On Wed, 20 Sep 2017 08:35:00 -0400, Raymond DeCampo wrote:
> On Wed, Sep 20, 2017 at 7:29 AM, Gilles 
> <>
> wrote:
>> On Sat, 16 Sep 2017 14:19:04 -0400, Raymond DeCampo wrote:
>>> [...]
>>>> So from the POV of a "Commons Numbers" developer, what is the
>>>> added value of "Field"?
>>>> [IMO none at the moment (but that could change).]
>>> I'm not looking at it from the POV of a CN developer.  I am looking 
>>> at it
>>> from the POV of a CN user.
>> If "Commons Numbers" were only to be a copy from what is/was
>> in CM I'd have to agree that there was no point in having a
>> new component in the first place.
> Well perhaps we have different philosophies here.  I thought the main 
> goal
> was to slice up CM into manageable pieces to allow for better 
> releases and
> to allow people to focus on the portions of the library which are 
> important
> to them without being held back by the portions which are not of 
> interest.
>> Since there are no users right now, it seems reasonable to
>> me that the KISS principle should apply.
>> I believe this is covered in the following
>>> paragraph you quoted.
>> It is a nice feature, but as with any feature implemented on
>> top of a more basic utility, we should first look for a solution
>> that is compatible with the upstream dependency.
>> Since Java is strongly typed and does not support duck typing 
>> without
>>>>> resorting to reflection gymnastics, there is currently no way to 
>>>>> write
>>>>> an
>>>>> algorithm using e.g. the add() method which could be applied to
>>>>> o.a.c.n.f.Fraction and o.a.c.n.c.Complex without duplication, 
>>>>> reflection
>>>>> or
>>>>> pointless wrapper extensions.
>> You may be right.
>> But is the CM solution the best we can do, now that it is
>> the moment where other solutions can be explored?
>> [...]
>>>> To be blunt I don't agree with the approach
>> Which one?
>> so I am not about to devote
>>> time and effort to supporting it.
>> You are smarter than I ever was, since I devoted a lot of time
>> to implement compromise decisions in CM, although I knew that
>> they were bad (and proven to be so later on).
>> You are definitely right that the wrapper approach takes a
>> lot of time, mainly because of the awful amount of duplication
>> in the CM unit tests classes.
>> [I spent countless hours fixing the same in the RNG code.]
>> I badly underestimated the task for "Fraction"/"BigFraction". :-/
>> I'm also not particularly interested in
>>> arguing about it.  So I have completed the portions where we have
>>> agreement
>>> and left the rest.
>>> Summarizing the other issues I found while trying to eliminate
>>> BigFraction,
>>> Fraction and Complex from CM:
>>> I found nine test classes which use FractionField, those would need 
>>> to be
>>> rewritten.  I imagine they could use a different Field 
>>> implementation
>>> without a great deal of difficulty.
>> You are quite right; the "main" code is easy to adapt.
>> Adapting the unit tests, however, is a nightmare (+100 errors).
>> And I don't understand why it had to be, since the common "Field"
>> interfaces should in principle have allowed to write a test base
>> class, with the actual types be automatically exercised through
>> factory subclasses.
> I think that the issue with the unit tests is that they used Fraction
> and/or BigFraction for this purpose, i.e. a convenient implementation 
> of
> FieldElement when one was needed.
>> I also found a couple of public methods in MatrixUtils that I 
>> imagine will
>>> need to be deleted.  I don't think they would be missed but OTOH 
>>> they were
>>> added because somebody wanted them.
>>> What you do propose to do about the ComplexField, FractionField and
>>> BigFractionField classes?  These were part of the CM API in the 
>>> last
>>> release are is the plan to just drop them?
>> I'd have thought they could be modified so that under the hood,
>> they use the "Numbers" implementations.
> The issue with this is that the Field interface specifies a method
> returning the corresponding FieldElement class.  So you need 
> FieldElement
> wrapper implementations for the classes as well.  Then all you are 
> doing is
> implementing delegating methods in Fraction/BigFraction/Complex with 
> the
> wrappers - it's enough to make you want to work in a language with 
> duck
> typing.
> I'm not in front of the code right now so I'm not sure this would 
> work but,
> how would you feel about including just the FieldElement interface 
> (name
> negotiable) in numbers and leaving Field in CM?

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

View raw message