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. > 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 math-related code for this to be a companion. Commons-lang and commons-collections are companions.
