On Sat, May 13, 2017 at 9:33 AM, Gilles <gil...@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 <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. > 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.