> 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. -Rob > > > Regards, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org