

My first thought is that adding geometry to commonsnumbers 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:


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 commonsnumbers 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/NUMBERS37> >
> > Comments, suggestions, objections?
> >
> > Regards,
> > Gilles
> >
> >
> > 
> > To unsubscribe, email: [hidden email]
> > For additional commands, email: [hidden email]
> >
> >
>

,Thanks
_____________________
*Amey Jadiye*
(+91 73 87 770 382)


On Thu, 11 May 2017 13:45:28 0400, Raymond DeCampo wrote:
> My first thought is that adding geometry to commonsnumbers 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

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


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 "numberlike", and be useful without having to depend on
a fullfledged 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 commonsnumbers 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/NUMBERS37>> >
>> > Comments, suggestions, objections?
>> >
>> > Regards,
>> > Gilles
>> >
>> >

To unsubscribe, email: [hidden email]
For additional commands, email: [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 "numberlike", and be useful without having to depend on
> a fullfledged geometry library.
That said, we can nevertheless consider whether "PlaneAngle" should
be defined in another module (rather than in "commonsnumberscore").
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 "commonsnumbersangle" 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 commonsnumbers 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/NUMBERS37>>> >
>>> > Comments, suggestions, objections?
>>> >
>>> > Regards,
>>> > Gilles
>>> >
>>> >

To unsubscribe, email: [hidden email]
For additional commands, email: [hidden email]


I still think that we should leave geometric concepts out of
commonsnumbers.
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 "numberlike", and be useful without having to depend on
>> a fullfledged geometry library.
>>
>
> That said, we can nevertheless consider whether "PlaneAngle" should
> be defined in another module (rather than in "commonsnumberscore").
>
> 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 "commonsnumbersangle" 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 commonsnumbers 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/NUMBERS37>>>> >
>>>> > Comments, suggestions, objections?
>>>> >
>>>> > Regards,
>>>> > Gilles
>>>> >
>>>> >
>>>>
>>>
>
> 
> To unsubscribe, email: [hidden email]
> For additional commands, email: [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
> commonsnumbers.
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 "numberlike", and be useful without having to depend on
>>> a fullfledged geometry library.
>>>
>>
>> That said, we can nevertheless consider whether "PlaneAngle" should
>> be defined in another module (rather than in "commonsnumberscore").
>>
>> 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 "commonsnumbersangle" 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 commonsnumbers 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/NUMBERS37>>>>>>
>>>>>> Comments, suggestions, objections?
>>>>>>
>>>>>> Regards,
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> 
>> To unsubscribe, email: [hidden email]
>> For additional commands, email: [hidden email]
>>
>>

To unsubscribe, email: [hidden email]
For additional commands, email: [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
> > commonsnumbers.
>
> 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.


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
>> > commonsnumbers.
>>
>> 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, email: [hidden email]
For additional commands, email: [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
>>> > commonsnumbers.
>>>
>>> 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, email: [hidden email]
> For additional commands, email: [hidden email]
>

To unsubscribe, email: [hidden email]
For additional commands, email: [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
>>>> > commonsnumbers.
>>>>
>>>> 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" (NUMBERS29 and NUMBERS34)
* "MathArrays" and "ResizeableDoubleArray" (NUMBERS30)
* "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, email: [hidden email]
For additional commands, email: [hidden email]


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
>>> > commonsnumbers.
>>>
>>> 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 mathrelated code for this to be a companion.
Commonslang and commonscollections are companions.


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
>>>> > commonsnumbers.
>>>>
>>>> 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 fullfledged 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 cleanup 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 mathrelated code for this to be a companion.
> Commonslang and commonscollections 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
readytouse "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, email: [hidden email]
For additional commands, email: [hidden email]


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
npmstyle 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
> npmstyle 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]>


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
>>>>> > commonsnumbers.
>>>>>
>>>>> 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 fullfledged 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 cleanup 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 mathrelated code for this to be a companion.
>> Commonslang and commonscollections 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
> readytouse "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 commonsnumbers. 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
>>>>>> > commonsnumbers.
>>>>>>
>>>>>> 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 fullfledged 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 cleanup 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 mathrelated code for this to be a
>>> companion.
>>> Commonslang and commonscollections 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
>> readytouse "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 commonsnumbers. 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 lessthanideal 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, email: [hidden email]
For additional commands, email: [hidden email]

