On Fri, 12 May 2017 19:26:08 -0400, Rob Tompkins wrote:
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.
Yes, although I didn't quite mean that what is not in "java.lang.Math"
should not belong to a "Commons" component. [That also does not hold
true for several components that do not have any direct counterparts
within the JDK.]
I think that we are almost done with the contents of "Commons Numbers";
a few other "utils" classes are still to be moved from CM (and possibly
refactored):
* "CombinatoricsUtils" and "Combinations" (NUMBERS-29 and NUMBERS-34)
* "MathArrays" and "ResizeableDoubleArray" (NUMBERS-30)
* "Beta" and "Erf"
* "IntegerSequence" and "MultidimensionalCounter"
Hopefully, those utilities will get more visibility when available
in their own modules rather than when accumulated within the
"o.a.c.math4.util" package.
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
