Re: [Math][Numbers] Move Field, etc. to numbers?
On Fri, Sep 15, 2017 at 9:59 PM, Gilles 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.
Re: svn commit: r1808564 - /commons/proper/jelly/trunk/NOTICE.txt
Thanks. I can pick this up later today as well. > On Sep 16, 2017, at 11:00 AM, ohe...@apache.org wrote: > > Author: oheger > Date: Sat Sep 16 15:00:57 2017 > New Revision: 1808564 > > URL: http://svn.apache.org/viewvc?rev=1808564&view=rev > Log: > Updated copyright date in NOTICE. > > Modified: >commons/proper/jelly/trunk/NOTICE.txt > > Modified: commons/proper/jelly/trunk/NOTICE.txt > URL: > http://svn.apache.org/viewvc/commons/proper/jelly/trunk/NOTICE.txt?rev=1808564&r1=1808563&r2=1808564&view=diff > == > --- commons/proper/jelly/trunk/NOTICE.txt (original) > +++ commons/proper/jelly/trunk/NOTICE.txt Sat Sep 16 15:00:57 2017 > @@ -1,5 +1,5 @@ > Apache Commons Jelly > -Copyright 2001-2016 The Apache Software Foundation > +Copyright 2001-2017 The Apache Software Foundation > > This product includes software developed at > The Apache Software Foundation (http://www.apache.org/). > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math][Numbers] Move Field, etc. to numbers?
On Sat, 16 Sep 2017 10:57:06 -0400, Raymond DeCampo wrote:
On Fri, Sep 15, 2017 at 9:59 PM, Gilles
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.
Once "Commons Numbers" is released, it will be too late; refactoring
such a base class would entail a top-level package name change!
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.
Of course, I agree with the above.
However there is a need to take various POV into account.
One of them is usefulness of an abstract concept in a "basic"
utility library like "Commons Numbers". "Numbers" utilities
are extracted from CM for a reason: because they are useful
on their own.
IIRC, there was a discussion whether we should go further than
"Field" in taking the mathematician's POV. The consensus was
"no" because there was no need in CM (and because CM was not
intended to be an implementation of any and all math concepts!).
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).]
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.
All I say is that I'm not convinced that "Field" and
"FieldElement" as they are now, is the best way to allow
that in either "Commons Numbers" or CM.
Have we explored other possible APIs?
E.g.:
interface Add {
T add(T other);
}
etc.
Can we leverage something from Java 8?
My feeling is that "Field" and "FieldElement" don't
look right... But I could be wrong. That they are
in CM is not a convincing argument.
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 meant "ad-hoc" as the thing needed to make "BigFraction" work
in "KolmogorovSmirnovTest". And at the same time, I question
the design of that "KolmogorovSmirnovTest" class and the
usefulness of the "Field"-related computations (as part of a
library mainly based on the "double" data type).
Recall that we are in that position because many codes are
not supported.
My rationale is that since we don't understand the details
of why "Filed" is used in "KolmogorovSmirnovTest", we should
not impose that API on "Commons Numbers".
Since "Field" is used by CM, it should stay there until we
can see the added value. [At that time we can add interfaces
to the API, hopefully without breaking compatibility.]
I'd much prefer that we create a "FieldElement" implementation
that is a bridge to "BigFraction" (from "Numbers") and make the
necessary changes in "KolmogorovSmi
Re: [Math][Numbers] Move Field, etc. to numbers?
On Sat, Sep 16, 2017 at 1:34 PM, Gilles
wrote:
> On Sat, 16 Sep 2017 10:57:06 -0400, Raymond DeCampo wrote:
>
>> On Fri, Sep 15, 2017 at 9:59 PM, Gilles
>> 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.
>>
>
> Once "Commons Numbers" is released, it will be too late; refactoring
> such a base class would entail a top-level package name change!
>
>
>
>> 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.
>>
>>
> Of course, I agree with the above.
> However there is a need to take various POV into account.
> One of them is usefulness of an abstract concept in a "basic"
> utility library like "Commons Numbers". "Numbers" utilities
> are extracted from CM for a reason: because they are useful
> on their own.
> IIRC, there was a discussion whether we should go further than
> "Field" in taking the mathematician's POV. The consensus was
> "no" because there was no need in CM (and because CM was not
> intended to be an implementation of any and all math concepts!).
>
> 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. I believe this is covered in the following
paragraph you quoted.
>
>
> 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.
>>
>
> All I say is that I'm not convinced that "Field" and
> "FieldElement" as they are now, is the best way to allow
> that in either "Commons Numbers" or CM.
>
> Have we explored other possible APIs?
> E.g.:
>
> interface Add {
> T add(T other);
> }
>
> etc
.
>
> Can we leverage something from Java 8?
>
> My feeling is that "Field" and "FieldElement" don't
> look right... But I could be wrong. That they are
> in CM is not a convincing argument.
>
> 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 meant "ad-hoc" as the thing needed to make "BigFraction" work
> in "KolmogorovSmirnovTest". And at the same time, I question
> the design of that "KolmogorovSmirnovTest" class and the
> usefulness of the "Field"-related computations (as part of a
> library mainly based on the "double" data type).
>
> Recall that we are in th
Re: [Math][Numbers] Move Field, etc. to numbers?
I am also not in favor of retaining the Field class. In the context of a
large mathematical library that was attempting to meaningfully fuse OOP
concepts with mathematical functionality it might make sense (although it
should be pointed out, all the mathematicians I know are not really
interested in this and happy with Maple and Matlab). In the context of
commons functionality, where we try to help Java programmers avoid
reinventing wheels, I don't think it makes a lot of sense.
What has (slowly) become Complex had some methods and classes that used
Field or its subclasses. I stripped them out. I don't think anyone is
interesting in implementing the old ComplexField class to analytically
solve complex functions. People just want to make up for the fact that Java
has no complex class the way C++ does.
On Sat, Sep 16, 2017 at 7:34 PM, Gilles
wrote:
> On Sat, 16 Sep 2017 10:57:06 -0400, Raymond DeCampo wrote:
>
>> On Fri, Sep 15, 2017 at 9:59 PM, Gilles
>> 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.
>>
>
> Once "Commons Numbers" is released, it will be too late; refactoring
> such a base class would entail a top-level package name change!
>
>
>
>> 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.
>>
>>
> Of course, I agree with the above.
> However there is a need to take various POV into account.
> One of them is usefulness of an abstract concept in a "basic"
> utility library like "Commons Numbers". "Numbers" utilities
> are extracted from CM for a reason: because they are useful
> on their own.
> IIRC, there was a discussion whether we should go further than
> "Field" in taking the mathematician's POV. The consensus was
> "no" because there was no need in CM (and because CM was not
> intended to be an implementation of any and all math concepts!).
>
> 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).]
>
> 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.
>>
>
> All I say is that I'm not convinced that "Field" and
> "FieldElement" as they are now, is the best way to allow
> that in either "Commons Numbers" or CM.
>
> Have we explored other possible APIs?
> E.g.:
>
> interface Add {
> T add(T other);
> }
>
> etc.
>
> Can we leverage something from Java 8?
>
> My feeling is that "Field" and "FieldElement" don't
> look right... But I could be wrong. That they are
> in CM is not a convincing argument.
>
> 3. There is a single identified need, in "KolmogorovSmirnovTest";
>>>and it is internal to it.
>>>
>>> Thus, I'd be wary to pollute
Re: [Math][Numbers] Move Field, etc. to numbers?
On Sep 15, 2017 5:30 PM, "Raymond DeCampo" wrote:
Re terminology a field is an abstract system of numbers so I don't see an
issue there.
Let E = {Dunhill, Camel},
Let Dunhill * Dunhill = Dunhill,
Dunhill * Camel = Dunhill,
Camel * Dunhill = Dunhill,
Camel * Camel = Camel
Let Dunhill + Dunhill = Dunhill,
Dunhill + Camel = Camel,
Camel + Dunhill = Camel,
Camel + Camel = Dunhill
Then is a Field, but of brands of cigarette.
So I vote Camel or Dunhill depending.
Simon
