commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Numbers] Angle class?
Date Sat, 13 May 2017 13:33:51 GMT
Hello Ray.

On Sat, 13 May 2017 07:29:13 -0400, Raymond DeCampo wrote:
> On Fri, May 12, 2017 at 6:49 PM, Gilles 
> <>
> wrote:
>> On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote:
>>> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <>
>>> wrote:
>>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <>

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

I don't quite follow.
My point is only that "angle" is used a lot without it being part
of a full-fledged geometry package.
[In CM, "normalizeAngle" is not in the package "geometry" simply
because of that common use. And IIRC there is no "Angle" class in
the "geometry" package... Here I'm not discussing whether it would
have been better to have it there...]

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

There is no rush; I'm doing the clean-up that must be done anyway.
"MathUtils" should be deleted (or made private) from CM, for the reason
given previously.

"Commons Numbers" can be easily released in the coming weeks (not so 
CM), and I really don't understand the reluctance to include such 
resources as an angle normalization routine.

If what you are worried about is that an ideal plane geometry library
would probably contain such a class a "PlaneAngle", I agree with you;
however, adding it now in CM without thoroughly reviewing the package
(with the input from actual users of that package) is a waste of time.
[Been there, done that, with the "optim" package...]

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

What is the overhead?
More html pages on the site?

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

Sorry, I don't follow.
Obviously, "Commons Numbers" contains stuff that is not in 
For some functionality, namely "PlaneAngle", "Commons Numbers" provides 
OO alternative to the static methods in the JDK class, and it provides 
ready-to-use "normalize()" method that is not in the JDK. [I've used 
the word
"companion" in that sense only.  But let's drop the discussion on the 
use of
words, please.  What I'm interested in, is that "Commons Numbers" 
utilities that stand on their own.  That they were formerly in CM is a 
issue, except that anything that makes CM "lighter" in a Good Thing 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message