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
>>> > commonsnumbers.
>>>
>>> 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 mathrelated code for this to be a companion.
Commonslang and commonscollections are companions.
