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 Sun, 14 May 2017 12:38:38 GMT
On Sat, May 13, 2017 at 9:33 AM, Gilles <gilles@harfang.homelinux.org>
wrote:

> Hello Ray.
>
>
> On Sat, 13 May 2017 07:29:13 -0400, Raymond DeCampo wrote:
>
>> 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.
>>
>
> 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.
>

My point is that an angle is always used in a geometrical context and
matrices are not.  It's a very simple point.


> [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 for
> CM), and I really don't understand the reluctance to include such common
> resources as an angle normalization routine.
>
> If what you are worried about is that an ideal plane geometry library
>

I think I have made it clear what I am worried about.


> 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 "java.lang.Math".
> For some functionality, namely "PlaneAngle", "Commons Numbers" provides an
> OO alternative to the static methods in the JDK class, and it provides a
> 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" groups
> utilities that stand on their own.  That they were formerly in CM is a non
> issue, except that anything that makes CM "lighter" in a Good Thing (TM).]
>
>
I appears to me that we are talking past each other at this point.

Perhaps a more fruitful discussion would be to define what the boundaries
are for commons-numbers.  Perhaps you could propose what your vision is
since you are dissatisfied with mine.

A second discussion concerning the minimum size for a module might also be
called for but that might be best saved for a different thread.

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