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).
2. The concept is fairly abstract (and indeed too "math-related"!).
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.
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".
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
