What would you do with FieldElement and in particular
FieldElement.getField()?
On Fri, Dec 22, 2017 at 10:42 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
> Hello.
>
> 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
> "Fraction".
>
> So, I'd wish to create a new module:
> commons-numbers-field
> with new classes such as "FractionField" that reflect
> the intended functionality[1].
>
> WDYT?
>
> 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
> utilities.
>
> Regards,
> Gilles
>
> [1] http://mathworld.wolfram.com/FieldAxioms.html
>
>
> On Wed, 20 Sep 2017 08:35:00 -0400, Raymond DeCampo wrote:
>
>> On Wed, Sep 20, 2017 at 7:29 AM, Gilles <gil...@harfang.homelinux.org>
>> 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: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
