commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond DeCampo <...@decampo.org>
Subject Re: [Numbers] Angle class?
Date Sat, 13 May 2017 11:29:13 GMT
On Fri, 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.]
>

The point is that matrices as a mathematical concept have utility outside
of geometry not that a program might make use of them without using
o.a.c.m.geometry.



> For such a simple and useful concept, it's unreasonable to wait for
> the rethinking of the whole of the "geometry" package to happen...
>

What's the rush to add this to numbers if equivalent functionality already
exists in java.lang.Math and CM MathUtils?



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

It's not the "bytes" it's the overhead.  Having a module containing only
one class is extreme.


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


I do not see this argument at all.  The JDK java.lang.Math class is a
collection of static utilities which are loosely related.  Following this
line of organization is a recipe to repeat the problems with CM.  Second, I
do not think of CM or "Commons Numbers" as companions to the JDK.  The JDK
does not provide enough math-related code for this to be a companion.
Commons-lang and commons-collections are companions.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message