Hi.
Please have a look at https://issues.apache.org/jira/browse/NUMBERS-37 Comments, suggestions, objections? Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
My first thought is that adding geometry to commons-numbers is too much
"scope creep" for lack of a better term. There's a lot of code under the org.apache.commons.math4.geometry package in CM. I guess I am wondering where we want to draw the line. Obviously we do not want all of CM in numbers or we will be back where we started when we began splitting it up. On Thu, May 11, 2017 at 10:46 AM, Gilles <[hidden email]> wrote: > Hi. > > Please have a look at > https://issues.apache.org/jira/browse/NUMBERS-37 > > Comments, suggestions, objections? > > Regards, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
Agreed with Raymond +1
If we want to make things modular I would prefer core should have very core part of numbers in CN which were in Commons Math and already separated in from CM to CN, as Angle is the part of geometry the package for it should be like. package some.pkg.geometry.core; IMHO PlaneAngle should be part of geometry. On Thu, May 11, 2017 at 11:15 PM, Raymond DeCampo <[hidden email]> wrote: > My first thought is that adding geometry to commons-numbers is too much > "scope creep" for lack of a better term. There's a lot of code under the > org.apache.commons.math4.geometry package in CM. > > I guess I am wondering where we want to draw the line. Obviously we do not > want all of CM in numbers or we will be back where we started when we began > splitting it up. > > > On Thu, May 11, 2017 at 10:46 AM, Gilles <[hidden email]> > wrote: > > > Hi. > > > > Please have a look at > > https://issues.apache.org/jira/browse/NUMBERS-37 > > > > Comments, suggestions, objections? > > > > Regards, > > Gilles > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > -- ,Thanks _____________________ *Amey Jadiye* (+91 73 87 770 382) |
In reply to this post by Raymond DeCampo
On Thu, 11 May 2017 13:45:28 -0400, Raymond DeCampo wrote:
> My first thought is that adding geometry to commons-numbers is too > much > "scope creep" for lack of a better term. There's a lot of code under > the > org.apache.commons.math4.geometry package in CM. > > I guess I am wondering where we want to draw the line. Obviously we > do not > want all of CM in numbers or we will be back where we started when we > began > splitting it up. Well said. ;-) Gilles > > On Thu, May 11, 2017 at 10:46 AM, Gilles > <[hidden email]> > wrote: > >> Hi. >> >> Please have a look at >> https://issues.apache.org/jira/browse/NUMBERS-37 >> >> Comments, suggestions, objections? >> >> Regards, >> Gilles >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Amey Jadiye
On Fri, 12 May 2017 01:43:24 +0530, Amey Jadiye wrote:
> Agreed with Raymond +1 > > If we want to make things modular I would prefer core should have > very core > part of numbers in CN which were in Commons Math and already > separated in > from CM to CN, as Angle is the part of geometry the package for it > should > be like. > > package some.pkg.geometry.core; > > IMHO PlaneAngle should be part of geometry. It is at the core of "geometry", but some basic functionalities can be seen as "number-like", and be useful without having to depend on a full-fledged geometry library. Regards, Gilles > > On Thu, May 11, 2017 at 11:15 PM, Raymond DeCampo <[hidden email]> > wrote: > >> My first thought is that adding geometry to commons-numbers is too >> much >> "scope creep" for lack of a better term. There's a lot of code >> under the >> org.apache.commons.math4.geometry package in CM. >> >> I guess I am wondering where we want to draw the line. Obviously we >> do not >> want all of CM in numbers or we will be back where we started when >> we began >> splitting it up. >> >> >> On Thu, May 11, 2017 at 10:46 AM, Gilles >> <[hidden email]> >> wrote: >> >> > Hi. >> > >> > Please have a look at >> > https://issues.apache.org/jira/browse/NUMBERS-37 >> > >> > Comments, suggestions, objections? >> > >> > Regards, >> > Gilles >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Thu, 11 May 2017 22:39:16 +0200, Gilles wrote:
> On Fri, 12 May 2017 01:43:24 +0530, Amey Jadiye wrote: >> Agreed with Raymond +1 >> >> If we want to make things modular I would prefer core should have >> very core >> part of numbers in CN which were in Commons Math and already >> separated in >> from CM to CN, as Angle is the part of geometry the package for it >> should >> be like. >> >> package some.pkg.geometry.core; >> >> IMHO PlaneAngle should be part of geometry. > > It is at the core of "geometry", but some basic functionalities can > be seen as "number-like", and be useful without having to depend on > a full-fledged geometry library. That said, we can nevertheless consider whether "PlaneAngle" should be defined in another module (rather than in "commons-numbers-core"). Do you think of other functionalities that would be grouped with "PlaneAngle" within their own module? [Perhaps that the potential of a future feature such as "SolidAngle" is already worth creating a "commons-numbers-angle" module]. Regards, Gilles > > Regards, > Gilles > >> >> On Thu, May 11, 2017 at 11:15 PM, Raymond DeCampo <[hidden email]> >> wrote: >> >>> My first thought is that adding geometry to commons-numbers is too >>> much >>> "scope creep" for lack of a better term. There's a lot of code >>> under the >>> org.apache.commons.math4.geometry package in CM. >>> >>> I guess I am wondering where we want to draw the line. Obviously >>> we do not >>> want all of CM in numbers or we will be back where we started when >>> we began >>> splitting it up. >>> >>> >>> On Thu, May 11, 2017 at 10:46 AM, Gilles >>> <[hidden email]> >>> wrote: >>> >>> > Hi. >>> > >>> > Please have a look at >>> > https://issues.apache.org/jira/browse/NUMBERS-37 >>> > >>> > Comments, suggestions, objections? >>> > >>> > Regards, >>> > Gilles >>> > >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
I still think that we should leave geometric concepts out of
commons-numbers. I also think we are chopping up the modules too fine. Here we have a module with one class and an intention to maybe introduce another. On Fri, May 12, 2017 at 8:24 AM, Gilles <[hidden email]> wrote: > On Thu, 11 May 2017 22:39:16 +0200, Gilles wrote: > >> On Fri, 12 May 2017 01:43:24 +0530, Amey Jadiye wrote: >> >>> Agreed with Raymond +1 >>> >>> If we want to make things modular I would prefer core should have very >>> core >>> part of numbers in CN which were in Commons Math and already separated in >>> from CM to CN, as Angle is the part of geometry the package for it >>> should >>> be like. >>> >>> package some.pkg.geometry.core; >>> >>> IMHO PlaneAngle should be part of geometry. >>> >> >> It is at the core of "geometry", but some basic functionalities can >> be seen as "number-like", and be useful without having to depend on >> a full-fledged geometry library. >> > > That said, we can nevertheless consider whether "PlaneAngle" should > be defined in another module (rather than in "commons-numbers-core"). > > Do you think of other functionalities that would be grouped with > "PlaneAngle" within their own module? > [Perhaps that the potential of a future feature such as "SolidAngle" > is already worth creating a "commons-numbers-angle" module]. > > > Regards, > Gilles > > > >> Regards, >> Gilles >> >> >>> On Thu, May 11, 2017 at 11:15 PM, Raymond DeCampo <[hidden email]> >>> wrote: >>> >>> My first thought is that adding geometry to commons-numbers is too much >>>> "scope creep" for lack of a better term. There's a lot of code under >>>> the >>>> org.apache.commons.math4.geometry package in CM. >>>> >>>> I guess I am wondering where we want to draw the line. Obviously we do >>>> not >>>> want all of CM in numbers or we will be back where we started when we >>>> began >>>> splitting it up. >>>> >>>> >>>> On Thu, May 11, 2017 at 10:46 AM, Gilles <[hidden email]> >>>> wrote: >>>> >>>> > Hi. >>>> > >>>> > Please have a look at >>>> > https://issues.apache.org/jira/browse/NUMBERS-37 >>>> > >>>> > Comments, suggestions, objections? >>>> > >>>> > Regards, >>>> > Gilles >>>> > >>>> > >>>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
> On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> 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. Just some thoughts… -Rob > > I also think we are chopping up the modules too fine. Here we have a > module with one class and an intention to maybe introduce another. > > On Fri, May 12, 2017 at 8:24 AM, Gilles <[hidden email]> > wrote: > >> On Thu, 11 May 2017 22:39:16 +0200, Gilles wrote: >> >>> On Fri, 12 May 2017 01:43:24 +0530, Amey Jadiye wrote: >>> >>>> Agreed with Raymond +1 >>>> >>>> If we want to make things modular I would prefer core should have very >>>> core >>>> part of numbers in CN which were in Commons Math and already separated in >>>> from CM to CN, as Angle is the part of geometry the package for it >>>> should >>>> be like. >>>> >>>> package some.pkg.geometry.core; >>>> >>>> IMHO PlaneAngle should be part of geometry. >>>> >>> >>> It is at the core of "geometry", but some basic functionalities can >>> be seen as "number-like", and be useful without having to depend on >>> a full-fledged geometry library. >>> >> >> That said, we can nevertheless consider whether "PlaneAngle" should >> be defined in another module (rather than in "commons-numbers-core"). >> >> Do you think of other functionalities that would be grouped with >> "PlaneAngle" within their own module? >> [Perhaps that the potential of a future feature such as "SolidAngle" >> is already worth creating a "commons-numbers-angle" module]. >> >> >> Regards, >> Gilles >> >> >> >>> Regards, >>> Gilles >>> >>> >>>> On Thu, May 11, 2017 at 11:15 PM, Raymond DeCampo <[hidden email]> >>>> wrote: >>>> >>>> My first thought is that adding geometry to commons-numbers is too much >>>>> "scope creep" for lack of a better term. There's a lot of code under >>>>> the >>>>> org.apache.commons.math4.geometry package in CM. >>>>> >>>>> I guess I am wondering where we want to draw the line. Obviously we do >>>>> not >>>>> want all of CM in numbers or we will be back where we started when we >>>>> began >>>>> splitting it up. >>>>> >>>>> >>>>> On Thu, May 11, 2017 at 10:46 AM, Gilles <[hidden email]> >>>>> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> Please have a look at >>>>>> https://issues.apache.org/jira/browse/NUMBERS-37 >>>>>> >>>>>> Comments, suggestions, objections? >>>>>> >>>>>> Regards, >>>>>> Gilles >>>>>> >>>>>> >>>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <[hidden email]> wrote:
> > > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> 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. > > 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. |
On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote:
> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <[hidden email]> > wrote: > >> >> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> >> 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. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
> On May 12, 2017, at 6:49 PM, Gilles <[hidden email]> wrote: > >> On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote: >>> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <[hidden email]> wrote: >>> >>> >>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> 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: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
On Fri, 12 May 2017 19:26:08 -0400, Rob Tompkins wrote:
>> On May 12, 2017, at 6:49 PM, Gilles <[hidden email]> >> wrote: >> >>> On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote: >>>> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins >>>> <[hidden email]> wrote: >>>> >>>> >>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> >>>> 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: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Gilles Sadowski
On Fri, May 12, 2017 at 6:49 PM, Gilles <[hidden email]>
wrote: > On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote: > >> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <[hidden email]> >> wrote: >> >> >>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> 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. |
In reply to this post by Gilles Sadowski
Hello Ray.
On Sat, 13 May 2017 07:29:13 -0400, Raymond DeCampo wrote: > On Fri, May 12, 2017 at 6:49 PM, Gilles > <[hidden email]> > wrote: > >> On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote: >> >>> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <[hidden email]> >>> wrote: >>> >>> >>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> >>>> 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: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by Raymond DeCampo
On 13 May 2017 at 06:29, Raymond DeCampo <[hidden email]> wrote:
> > > 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 I find amusing here is that if there were a standard an easy way to share artefacts containing only a single class file, we'd end up with an npm-style ecosystem where a basic project would require downloading and maintaining dozens or hundreds of dependencies without doing anything particularly special. When it comes down to it, finding a proper point of modularisation is difficult as there are trade offs in maintenance versus purity. Since Java still doesn't have any good way to enforce automatic semantic versioning and simple code isolation (JPMS in Java 9 refuses to address this still which was one of Red Hat's criticisms), we're stuck bundling a bunch of somewhat related code together just for usability purposes. Contract this with the C development world where libraries pride themselves on being distributable as a single source file for simplicity (even though said file is usually thousands of lines long). -- Matt Sicker <[hidden email]> |
I'd also like to add that I'm not sure comparing what's included in
java.lang and other old Java packages isn't the best indicator of modularisation. Sure, you could say that about newer Java releases where there was quite a bit more discipline toward breaking functionality up into appropriate packages, but when you compare that with what was available since Java 1.0 or 1.1 or so, you may notice that original versions of Java weren't so disciplined about it (which seems to be a pretty typical way that Java libraries are developed where the original version doesn't have to break everything up so fine grained just yet). On 13 May 2017 at 13:50, Matt Sicker <[hidden email]> wrote: > On 13 May 2017 at 06:29, Raymond DeCampo <[hidden email]> wrote: >> >> > 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 I find amusing here is that if there were a standard an easy way to > share artefacts containing only a single class file, we'd end up with an > npm-style ecosystem where a basic project would require downloading and > maintaining dozens or hundreds of dependencies without doing anything > particularly special. When it comes down to it, finding a proper point of > modularisation is difficult as there are trade offs in maintenance versus > purity. Since Java still doesn't have any good way to enforce automatic > semantic versioning and simple code isolation (JPMS in Java 9 refuses to > address this still which was one of Red Hat's criticisms), we're stuck > bundling a bunch of somewhat related code together just for usability > purposes. Contract this with the C development world where libraries pride > themselves on being distributable as a single source file for simplicity > (even though said file is usually thousands of lines long). > > -- > Matt Sicker <[hidden email]> > -- Matt Sicker <[hidden email]> |
In reply to this post by Gilles Sadowski
On Sat, May 13, 2017 at 9:33 AM, Gilles <[hidden email]>
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 <[hidden email]> >> wrote: >> >> On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote: >>> >>> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <[hidden email]> >>>> wrote: >>>> >>>> >>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> >>>>> 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. > > 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).] > > 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. |
Hi.
On Sun, 14 May 2017 08:38:38 -0400, Raymond DeCampo wrote: > On Sat, May 13, 2017 at 9:33 AM, Gilles > <[hidden email]> > 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 >>> <[hidden email]> >>> wrote: >>> >>> On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote: >>>> >>>> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins >>>> <[hidden email]> >>>>> wrote: >>>>> >>>>> >>>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <[hidden email]> >>>>>> 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. Quite the contrary, in an ideal world, I'd completely agree with strictly limiting the scope of a component. However, we are in the less-than-ideal world of "Commons" (for good or bad). Please recall that I wanted to limit the scope of "Commons RNG", but in the absence of consensus about creating yet another component, it has not been possible: either I'd put in "sampling" (even though _not_ in scope according to my argument), or I'd have had to forego providing this functionality. The same goes for all the packages which I've called to be factored out of "Commons Math". Ideally, we'd create one component per functionality. But practically, the PMC is against this approach; and the main argument was unrelated to scope (more work for release reviews). Hence, on the one hand, there seems to be a limit on the number of components and on the other, there is the need to fix "Commons Math" (in the sense which I've also developed extensively elsewhere). The sole compromise I see currently is to (slightly) loosen the threshold of acceptance into "Commons Numbers", creating modules as necessary in order to stress the separation of scopes. > 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. Cf. Matt's comments on this; IIUC his point, the whole range of practices exists, from one single file for a whole library, to one file per function. Unless I'm deeply mistaken, the evolution of practice is towards the latter. So, indeed, size does not matter. :-) Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Free forum by Nabble | Edit this page |