[Math][Numbers] Move Field, etc. to numbers?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[Math][Numbers] Move Field, etc. to numbers?

Raymond DeCampo
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?
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Raymond DeCampo
On Fri, Sep 15, 2017 at 9:59 PM, Gilles <[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Gilles Sadowski
On Sat, 16 Sep 2017 10:57:06 -0400, Raymond DeCampo wrote:

> On Fri, Sep 15, 2017 at 9:59 PM, Gilles
> <[hidden email]>
> 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> {
   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 "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 cringe on
* the name (Are we sure that any class implementing the API would
   define a field?)
* the use of reflection
* the use of wildcard
* the use of "on-demand" loading

Again, perhaps there is no way around.
But no documentation justifies those choices.

>
> 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.

I don't understand this line of reasoning.
I made the changes already, and "KolmogorovSmirnovTest" still
passes all its unit tests.  Is there another place in CM
where the "Field" nature of "BigFraction" is needed?
If not, it can be replaced by its "Numbers" equivalent.
I.e. you could
  1. do most of what you intended,
  2. open a JIRA issue about "KolmogorovSmirnovTest"
which I'll try to fix as I proposed.

WDYT?

Regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Raymond DeCampo
On Sat, Sep 16, 2017 at 1:34 PM, Gilles <[hidden email]>
wrote:

> On Sat, 16 Sep 2017 10:57:06 -0400, Raymond DeCampo wrote:
>
>> On Fri, Sep 15, 2017 at 9:59 PM, Gilles <[hidden email]>
>> 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> {
>   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 "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 cringe on
> * the name (Are we sure that any class implementing the API would
>   define a field?)
> * the use of reflection
> * the use of wildcard
> * the use of "on-demand" loading
>
> Again, perhaps there is no way around.
> But no documentation justifies those choices.
>
>
>> 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.
>>
>
> I don't understand this line of reasoning.
> I made the changes already, and "KolmogorovSmirnovTest" still
> passes all its unit tests.

  Is there another place in CM

> where the "Field" nature of "BigFraction" is needed?
> If not, it can be replaced by its "Numbers" equivalent.
> I.e. you could
>  1. do most of what you intended,
>  2. open a JIRA issue about "KolmogorovSmirnovTest"
> which I'll try to fix as I proposed.
>
> WDYT?
>
>
To be blunt I don't agree with the approach so I am not about to devote
time and effort to supporting it.  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.

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?
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Eric Barnhill
In reply to this post by Gilles Sadowski
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 <[hidden email]>
wrote:

> On Sat, 16 Sep 2017 10:57:06 -0400, Raymond DeCampo wrote:
>
>> On Fri, Sep 15, 2017 at 9:59 PM, Gilles <[hidden email]>
>> 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> {
>   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 "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 cringe on
> * the name (Are we sure that any class implementing the API would
>   define a field?)
> * the use of reflection
> * the use of wildcard
> * the use of "on-demand" loading
>
> Again, perhaps there is no way around.
> But no documentation justifies those choices.
>
>
>> 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.
>>
>
> I don't understand this line of reasoning.
> I made the changes already, and "KolmogorovSmirnovTest" still
> passes all its unit tests.  Is there another place in CM
> where the "Field" nature of "BigFraction" is needed?
> If not, it can be replaced by its "Numbers" equivalent.
> I.e. you could
>  1. do most of what you intended,
>  2. open a JIRA issue about "KolmogorovSmirnovTest"
> which I'll try to fix as I proposed.
>
> WDYT?
>
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Simon Spero
In reply to this post by Raymond DeCampo
On Sep 15, 2017 5:30 PM, "Raymond DeCampo" <[hidden email]> 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 <E,+,*> is a Field, but of brands of cigarette.

 So I vote Camel or Dunhill depending.

Simon
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Gilles Sadowski
In reply to this post by Raymond DeCampo
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.

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 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.

Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Raymond DeCampo
On Wed, Sep 20, 2017 at 7:29 AM, Gilles <[hidden email]>
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?
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Gilles Sadowski
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
> <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Raymond DeCampo
What would you do with FieldElement and in particular
FieldElement.getField()?

On Fri, Dec 22, 2017 at 10:42 AM, Gilles <[hidden email]>
wrote:

> 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 <[hidden email]>
>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Gilles Sadowski
On Sat, 23 Dec 2017 15:35:14 -0500, Raymond DeCampo wrote:
> What would you do with FieldElement and in particular
> FieldElement.getField()?

I was thinking of a new interface to represent the "field"
concept:
---CUT---
/**
  * @param <T> Type of field element.
  */
public interface MathField<T> {
   T add(T a, T b);
   T multiply(T a, T b);
   // etc.
   T one();
   T zero();
}
---CUT---
to contain all the field-defining methods.

Some algorithm that can be defined on any field would be
instantiated with a reference to a "MathField":
---CUT---
public class LinearCombination<T> {
   private MathField<T> field;

   public LinearCombination<T>(MathField<T> field) {
     this.field = field;
   }

   public T compute(T[] a, T[] b) {
     T result = field.zero();
     for (int i = 0; i < a.length; i++) {
       result = field.add(result, field.multiply(a[i], b[i]));
     }
     return result;
   }
}
---CUT---

Does that make sense?

Gilles

> On Fri, Dec 22, 2017 at 10:42 AM, Gilles
> <[hidden email]>
> wrote:
>
>> 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
>>> <[hidden email]>
>>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Raymond DeCampo
On Sat, Dec 23, 2017 at 8:11 PM, Gilles <[hidden email]>
wrote:

> On Sat, 23 Dec 2017 15:35:14 -0500, Raymond DeCampo wrote:
>
>> What would you do with FieldElement and in particular
>> FieldElement.getField()?
>>
>
> I was thinking of a new interface to represent the "field"
> concept:
> ---CUT---
> /**
>  * @param <T> Type of field element.
>  */
> public interface MathField<T> {
>   T add(T a, T b);
>   T multiply(T a, T b);
>   // etc.
>   T one();
>   T zero();
> }
> ---CUT---
> to contain all the field-defining methods.
>
> Some algorithm that can be defined on any field would be
> instantiated with a reference to a "MathField":
> ---CUT---
> public class LinearCombination<T> {
>   private MathField<T> field;
>
>   public LinearCombination<T>(MathField<T> field) {
>     this.field = field;
>   }
>
>   public T compute(T[] a, T[] b) {
>     T result = field.zero();
>     for (int i = 0; i < a.length; i++) {
>       result = field.add(result, field.multiply(a[i], b[i]));
>     }
>     return result;class
>   }
> }
> ---CUT---
>
> Does that make sense?
>
>
Then we would have something like:

public class FractionField implements MathField<Fraction> {

    public Fraction add(Fraction a, Fraction b) {
        return a.add(b);
    }
    // etc.
}

Maybe we should create a branch in either numbers or CM (or both) to play
with it and see how it goes?  But probably not until after the holiday.

I'm still thinking it would be nice to have an interface which Fraction,
Complex, etc could implement allowing a base MathField implementation:

public abstract class AbstractMathField<T extends FieldElement> implements
MathField<T> {

    public T add(T a, T b) {
        return a.add(b);
    }
    // etc.
}

Then there would be less repeated boilerplate in MathField implementations.
Reply | Threaded
Open this post in threaded view
|

Re: [Math][Numbers] Move Field, etc. to numbers?

Gilles Sadowski
On Sun, 24 Dec 2017 19:47:23 -0500, Raymond DeCampo wrote:

> On Sat, Dec 23, 2017 at 8:11 PM, Gilles
> <[hidden email]>
> wrote:
>
>> On Sat, 23 Dec 2017 15:35:14 -0500, Raymond DeCampo wrote:
>>
>>> What would you do with FieldElement and in particular
>>> FieldElement.getField()?
>>>
>>
>> I was thinking of a new interface to represent the "field"
>> concept:
>> ---CUT---
>> /**
>>  * @param <T> Type of field element.
>>  */
>> public interface MathField<T> {
>>   T add(T a, T b);
>>   T multiply(T a, T b);
>>   // etc.
>>   T one();
>>   T zero();
>> }
>> ---CUT---
>> to contain all the field-defining methods.
>>
>> Some algorithm that can be defined on any field would be
>> instantiated with a reference to a "MathField":
>> ---CUT---
>> public class LinearCombination<T> {
>>   private MathField<T> field;
>>
>>   public LinearCombination<T>(MathField<T> field) {
>>     this.field = field;
>>   }
>>
>>   public T compute(T[] a, T[] b) {
>>     T result = field.zero();
>>     for (int i = 0; i < a.length; i++) {
>>       result = field.add(result, field.multiply(a[i], b[i]));
>>     }
>>     return result;class
>>   }
>> }
>> ---CUT---
>>
>> Does that make sense?
>>
>>
> Then we would have something like:
>
> public class FractionField implements MathField<Fraction> {
>
>     public Fraction add(Fraction a, Fraction b) {
>         return a.add(b);
>     }
>     // etc.
> }
>
> Maybe we should create a branch in either numbers

I'll do that.

> or CM

I'm overwhelmed by the number of changes needed in huge classes
such as "FieldMatrix" and "FieldVector". [And I feel that those
are misnomers...]

> (or both) to play
> with it and see how it goes?  But probably not until after the
> holiday.

OK. Have a nice holidays.

>
> I'm still thinking it would be nice to have an interface which
> Fraction,
> Complex, etc could implement allowing a base MathField
> implementation:
>
> public abstract class AbstractMathField<T extends FieldElement>
> implements
> MathField<T> {
>
>     public T add(T a, T b) {
>         return a.add(b);
>     }
>     // etc.
> }
>
> Then there would be less repeated boilerplate in MathField
> implementations.

It is probably fine to have a "FieldElement" interface (in module
"commons-numbers-core"): apart from its "advanced" usage in tools
such as exist in CM, it could be seen, in "Numbers", as a way to
ensure consistent naming of the basic operators.

The "AbstractMathField" class can also contain code for a singleton
instance for each type of field.


Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]