commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Numbers] Angle class?
Date Sat, 13 May 2017 00:23:53 GMT
On Fri, 12 May 2017 19:26:08 -0400, Rob Tompkins wrote:
>> On May 12, 2017, at 6:49 PM, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>
>>> On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote:
>>>> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins 
>>>> <chtompki@gmail.com> wrote:
>>>>
>>>>
>>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <ray@decampo.org>

>>>> wrote:
>>>> >
>>>> > I still think that we should leave geometric concepts out of
>>>> > commons-numbers.
>>>>
>>>> Are we defining numbers using the fundamental theorem of Algebra? 
>>>> Maybe,
>>>> that’s what should go in core?
>>>>
>>>> Clearly that would leave out the quaternions, matrices (which have 
>>>> an
>>>> implicit geometrical bias), and other constructions out of numbers 
>>>> from the
>>>> Complex Field.
>>>>
>>>>
>>> It's less about what the definition of "number" is and more about 
>>> setting
>>> some boundaries as to what belongs and what does not.  Geometry is 
>>> a
>>> convenient boundary in my eyes.
>>>
>>> If PlaneAngle belongs in numbers, shouldn't Plane from CM also 
>>> belong?  And
>>> if Plane is in, shouldn't Line be there?  And so on and so on.  
>>> It's
>>> tougher to draw the line (no pun intended) with PlaneAngle 
>>> included.
>>>
>>> Matrices are not exclusively used in a geometric setting so I don't 
>>> see a
>>> problem there.
>>
>> And the same goes for "angle".  [I've a class that uses the method
>> "MathUtils.normalizeAngle" from "Commons Math" and nothing from its
>> "o.a.c.m.geometry" package.]
>> For such a simple and useful concept, it's unreasonable to wait for
>> the rethinking of the whole of the "geometry" package to happen...
>>
>> As for the module, do we mind a few more bytes?
>> It leaves room for expansion (not that I intend to do it 
>> personally),
>> and it avoids that "core" becomes the place where we put every 
>> little
>> thing that does not belong elsewhere.  [If it turns out that "core"
>> contains only two classes, a question might be whether those should
>> not also belong to their own module with a name that better reflects
>> its content.]
>>
>> Lastly, if "Commons Numbers", as several other components, is also 
>> taken
>> as a companion to the JDK, then having "toRadians()" and 
>> "toDegrees()"
>> methods defined in "java.lang.Math" makes "PlaneAngle" a natural 
>> fit.
>
> That make sense to me. If we're going to forgo the natural
> delineations that derive from the algebraic structures, then using
> java.lang.Math as a guide for boundaries on the component seems quite
> natural.

Yes, although I didn't quite mean that what is not in "java.lang.Math"
should not belong to a "Commons" component. [That also does not hold
true for several components that do not have any direct counterparts
within the JDK.]

I think that we are almost done with the contents of "Commons Numbers";
a few other "utils" classes are still to be moved from CM (and possibly
refactored):
  * "CombinatoricsUtils" and "Combinations" (NUMBERS-29 and NUMBERS-34)
  * "MathArrays" and "ResizeableDoubleArray" (NUMBERS-30)
  * "Beta" and "Erf"
  * "IntegerSequence" and "MultidimensionalCounter"

Hopefully, those utilities will get more visibility when available
in their own modules rather than when accumulated within the
"o.a.c.math4.util" package.


Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message