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
