On Fri, Sep 15, 2017 at 9:59 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Fri, 15 Sep 2017 17:30:26 -0400, Raymond DeCampo wrote: > >> So I was trying to work through MATH-1416, which is to remove code from CM >> which has been moved to CN and I ran into a snag when trying to replace >> o.a.c.math4.f.BigFraction with the version from CN in >> the KolmogorovSmirnovTest class. This class uses o.a.c.m.f.BigFraction as >> an implementation of FieldElement which o.a.c.n.f.BigFraction is not since >> FieldElement is in CM and not in CN. >> >> I started down the road of creating an extension of >> o.a.c.numbers.f.BigFraction which implemented FieldElement, but that >> started to get sticky and complex and did not feel like the right answer. >> >> I seems like the right answer is to move Field, FieldElement and >> RealFieldElement into numbers and then BigFraction, Fraction, etc. can >> implement FieldElement again. This would mean no awkward bridge code to >> stuff o.a.c.numbers.f.BigFraction into a FieldElement implementation. >> >> Re terminology a field is an abstract system of numbers so I don't see an >> issue there. >> >> Following the existing convention I would create a commons-numbers-field >> submodule for the moved classes. >> >> Any objections? >> > > Yes, at least three: > > 1. "Field" and "FieldElement" themselves look awkward. I've alway > had a bad feeling about them, although I never had the urge to > find a way to fix them (or convince myself that there was no > better implementation). > This strikes me as the wrong time to try to refactor or replace them. > 2. The concept is fairly abstract (and indeed too "math-related"!). > Putting aside the idea that something is too math-related for CM or CN, while the concept of a field is an abstract mathematical concept, it strikes me that the interfaces based on it are very useful from a CS point of view as well. The interfaces establish that a particular Number representation follows certain rules and implements certain operations. So if one develops an algorithm which restricts itself to these rules it may be applied to many different Number classes. 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. > 3. There is a single identified need, in "KolmogorovSmirnovTest"; > and it is internal to it. > > Thus, I'd be wary to pollute "Numbers" with what seems an ad-hoc > API that has a single CM class as the only target. > >From what I have seen Field and FieldElement are used extensively in CM and hardly seem like an ad-hoc API. I suspect this will be the tip of the proverbial rabbit hole to mix a few metaphors. > > I'd much prefer that we create a "FieldElement" implementation > that is a bridge to "BigFraction" (from "Numbers") and make the > necessary changes in "KolmogorovSmirnovTest". > I've done it (mostly: class renames are in order that can be done > once "BigFraction" is deleted from CM); if you file report in JIRA, > I'll attach the files to it, for you to review. > [Admittingly, code in "KolmogorovSmirnovTest" will become slightly > more convoluted because of the bridge; however IMHO the whole class > could welcome a thorough cleanup...] > Until issue (1) above is solved, we should even make the bridge > utilities internal to "KolmogorovSmirnovTest". > > Unless I have misunderstood, issue (1) appears to be that you do not like the Field and FieldElement interfaces. I haven't a clue how to go about resolving that. I don't have time to go spelunking into the KolmogorovSmirnovTest now, I was looking for something I could knock off without a big time commitment to help get CN ready for release. So I will skip the removal of BigFraction for now.
