Hello Ray.
On Sat, 13 May 2017 07:29:13 -0400, Raymond DeCampo wrote:
On Fri, 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.]
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
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
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).]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org