> On May 12, 2017, at 6:49 PM, Gilles <gil...@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 <chtom...@gmail.com> wrote:
>>> 
>>> 
>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <r...@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. 

-Rob

> 
> 
> Regards,
> Gilles
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

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

Reply via email to