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?
