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 = Ca
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 i
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 remov
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 wh
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.
>
> Modifie
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
