You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2017/05/11 14:46:51 UTC
[Numbers] Angle class?
Hi.
Please have a look at
https://issues.apache.org/jira/browse/NUMBERS-37
Comments, suggestions, objections?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Gilles <gi...@harfang.homelinux.org>.
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
> <gi...@harfang.homelinux.org>
> wrote:
>
>> Hi.
>>
>> Please have a look at
>> https://issues.apache.org/jira/browse/NUMBERS-37
>>
>> Comments, suggestions, objections?
>>
>> Regards,
>> Gilles
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 12 May 2017 19:26:08 -0400, Rob Tompkins wrote:
>> On May 12, 2017, at 6:49 PM, Gilles <gi...@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
>>>> <ch...@gmail.com> wrote:
>>>>
>>>>
>>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <ra...@decampo.org>
>>>> wrote:
>>>> >
>>>> > I still think that we should leave geometric concepts out of
>>>> > commons-numbers.
>>>>
>>>> Are we defining numbers using the fundamental theorem of Algebra?
>>>> Maybe,
>>>> that’s what should go in core?
>>>>
>>>> Clearly that would leave out the quaternions, matrices (which have
>>>> an
>>>> implicit geometrical bias), and other constructions out of numbers
>>>> from the
>>>> Complex Field.
>>>>
>>>>
>>> It's less about what the definition of "number" is and more about
>>> setting
>>> some boundaries as to what belongs and what does not. Geometry is
>>> a
>>> convenient boundary in my eyes.
>>>
>>> If PlaneAngle belongs in numbers, shouldn't Plane from CM also
>>> belong? And
>>> if Plane is in, shouldn't Line be there? And so on and so on.
>>> It's
>>> tougher to draw the line (no pun intended) with PlaneAngle
>>> included.
>>>
>>> Matrices are not exclusively used in a geometric setting so I don't
>>> see a
>>> problem there.
>>
>> And the same goes for "angle". [I've a class that uses the method
>> "MathUtils.normalizeAngle" from "Commons Math" and nothing from its
>> "o.a.c.m.geometry" package.]
>> For such a simple and useful concept, it's unreasonable to wait for
>> the rethinking of the whole of the "geometry" package to happen...
>>
>> As for the module, do we mind a few more bytes?
>> It leaves room for expansion (not that I intend to do it
>> personally),
>> and it avoids that "core" becomes the place where we put every
>> little
>> thing that does not belong elsewhere. [If it turns out that "core"
>> contains only two classes, a question might be whether those should
>> not also belong to their own module with a name that better reflects
>> its content.]
>>
>> Lastly, if "Commons Numbers", as several other components, is also
>> taken
>> as a companion to the JDK, then having "toRadians()" and
>> "toDegrees()"
>> methods defined in "java.lang.Math" makes "PlaneAngle" a natural
>> fit.
>
> That make sense to me. If we're going to forgo the natural
> delineations that derive from the algebraic structures, then using
> java.lang.Math as a guide for boundaries on the component seems quite
> natural.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 12, 2017, at 6:49 PM, Gilles <gi...@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 <ch...@gmail.com> wrote:
>>>
>>>
>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <ra...@decampo.org> wrote:
>>> >
>>> > I still think that we should leave geometric concepts out of
>>> > commons-numbers.
>>>
>>> Are we defining numbers using the fundamental theorem of Algebra? Maybe,
>>> that’s what should go in core?
>>>
>>> Clearly that would leave out the quaternions, matrices (which have an
>>> implicit geometrical bias), and other constructions out of numbers from the
>>> Complex Field.
>>>
>>>
>> It's less about what the definition of "number" is and more about setting
>> some boundaries as to what belongs and what does not. Geometry is a
>> convenient boundary in my eyes.
>>
>> If PlaneAngle belongs in numbers, shouldn't Plane from CM also belong? And
>> if Plane is in, shouldn't Line be there? And so on and so on. It's
>> tougher to draw the line (no pun intended) with PlaneAngle included.
>>
>> Matrices are not exclusively used in a geometric setting so I don't see a
>> problem there.
>
> And the same goes for "angle". [I've a class that uses the method
> "MathUtils.normalizeAngle" from "Commons Math" and nothing from its
> "o.a.c.m.geometry" package.]
> For such a simple and useful concept, it's unreasonable to wait for
> the rethinking of the whole of the "geometry" package to happen...
>
> As for the module, do we mind a few more bytes?
> It leaves room for expansion (not that I intend to do it personally),
> and it avoids that "core" becomes the place where we put every little
> thing that does not belong elsewhere. [If it turns out that "core"
> contains only two classes, a question might be whether those should
> not also belong to their own module with a name that better reflects
> its content.]
>
> Lastly, if "Commons Numbers", as several other components, is also taken
> as a companion to the JDK, then having "toRadians()" and "toDegrees()"
> methods defined in "java.lang.Math" makes "PlaneAngle" a natural fit.
That make sense to me. If we're going to forgo the natural delineations that derive from the algebraic structures, then using java.lang.Math as a guide for boundaries on the component seems quite natural.
-Rob
>
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@gmail.com> wrote:
> On 13 May 2017 at 06:29, Raymond DeCampo <ra...@decampo.org> 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 <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: [Numbers] Angle class?
Posted by Matt Sicker <bo...@gmail.com>.
On 13 May 2017 at 06:29, Raymond DeCampo <ra...@decampo.org> 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 <bo...@gmail.com>
Re: [Numbers] Angle class?
Posted by Raymond DeCampo <ra...@decampo.org>.
On Fri, May 12, 2017 at 6:49 PM, Gilles <gi...@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 <ch...@gmail.com>
>> wrote:
>>
>>
>>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <ra...@decampo.org> wrote:
>>> >
>>> > I still think that we should leave geometric concepts out of
>>> > commons-numbers.
>>>
>>> Are we defining numbers using the fundamental theorem of Algebra? Maybe,
>>> that’s what should go in core?
>>>
>>> Clearly that would leave out the quaternions, matrices (which have an
>>> implicit geometrical bias), and other constructions out of numbers from
>>> the
>>> Complex Field.
>>>
>>>
>>> It's less about what the definition of "number" is and more about setting
>> some boundaries as to what belongs and what does not. Geometry is a
>> convenient boundary in my eyes.
>>
>> If PlaneAngle belongs in numbers, shouldn't Plane from CM also belong?
>> And
>> if Plane is in, shouldn't Line be there? And so on and so on. It's
>> tougher to draw the line (no pun intended) with PlaneAngle included.
>>
>> Matrices are not exclusively used in a geometric setting so I don't see a
>> problem there.
>>
>
> And the same goes for "angle". [I've a class that uses the method
> "MathUtils.normalizeAngle" from "Commons Math" and nothing from its
> "o.a.c.m.geometry" package.]
>
The point is that matrices as a mathematical concept have utility outside
of geometry not that a program might make use of them without using
o.a.c.m.geometry.
> For such a simple and useful concept, it's unreasonable to wait for
> the rethinking of the whole of the "geometry" package to happen...
>
What's the rush to add this to numbers if equivalent functionality already
exists in java.lang.Math and CM MathUtils?
>
> As for the module, do we mind a few more bytes?
> It leaves room for expansion (not that I intend to do it personally),
> and it avoids that "core" becomes the place where we put every little
> thing that does not belong elsewhere. [If it turns out that "core"
> contains only two classes, a question might be whether those should
> not also belong to their own module with a name that better reflects
> its content.]
>
It's not the "bytes" it's the overhead. Having a module containing only
one class is extreme.
>
> Lastly, if "Commons Numbers", as several other components, is also taken
> as a companion to the JDK, then having "toRadians()" and "toDegrees()"
> methods defined in "java.lang.Math" makes "PlaneAngle" a natural fit.
I do not see this argument at all. The JDK java.lang.Math class is a
collection of static utilities which are loosely related. Following this
line of organization is a recipe to repeat the problems with CM. Second, I
do not think of CM or "Commons Numbers" as companions to the JDK. The JDK
does not provide enough math-related code for this to be a companion.
Commons-lang and commons-collections are companions.
Re: [Numbers] Angle class?
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 12 May 2017 13:31:46 -0400, Raymond DeCampo wrote:
> On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <ch...@gmail.com>
> wrote:
>
>>
>> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <ra...@decampo.org>
>> wrote:
>> >
>> > I still think that we should leave geometric concepts out of
>> > commons-numbers.
>>
>> Are we defining numbers using the fundamental theorem of Algebra?
>> Maybe,
>> that’s what should go in core?
>>
>> Clearly that would leave out the quaternions, matrices (which have
>> an
>> implicit geometrical bias), and other constructions out of numbers
>> from the
>> Complex Field.
>>
>>
> It's less about what the definition of "number" is and more about
> setting
> some boundaries as to what belongs and what does not. Geometry is a
> convenient boundary in my eyes.
>
> If PlaneAngle belongs in numbers, shouldn't Plane from CM also
> belong? And
> if Plane is in, shouldn't Line be there? And so on and so on. It's
> tougher to draw the line (no pun intended) with PlaneAngle included.
>
> Matrices are not exclusively used in a geometric setting so I don't
> see a
> problem there.
And the same goes for "angle". [I've a class that uses the method
"MathUtils.normalizeAngle" from "Commons Math" and nothing from its
"o.a.c.m.geometry" package.]
For such a simple and useful concept, it's unreasonable to wait for
the rethinking of the whole of the "geometry" package to happen...
As for the module, do we mind a few more bytes?
It leaves room for expansion (not that I intend to do it personally),
and it avoids that "core" becomes the place where we put every little
thing that does not belong elsewhere. [If it turns out that "core"
contains only two classes, a question might be whether those should
not also belong to their own module with a name that better reflects
its content.]
Lastly, if "Commons Numbers", as several other components, is also
taken
as a companion to the JDK, then having "toRadians()" and "toDegrees()"
methods defined in "java.lang.Math" makes "PlaneAngle" a natural fit.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Raymond DeCampo <ra...@decampo.org>.
On Fri, May 12, 2017 at 12:27 PM, Rob Tompkins <ch...@gmail.com> wrote:
>
> > On May 12, 2017, at 11:49 AM, Raymond DeCampo <ra...@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.
Re: [Numbers] Angle class?
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 12, 2017, at 11:49 AM, Raymond DeCampo <ra...@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.
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 <gi...@harfang.homelinux.org>
> 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 <ra...@decampo.org>
>>>> 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 <gi...@harfang.homelinux.org>
>>>>> wrote:
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> Please have a look at
>>>>>> https://issues.apache.org/jira/browse/NUMBERS-37
>>>>>>
>>>>>> Comments, suggestions, objections?
>>>>>>
>>>>>> Regards,
>>>>>> Gilles
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Raymond DeCampo <ra...@decampo.org>.
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 <gi...@harfang.homelinux.org>
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 <ra...@decampo.org>
>>> 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 <gi...@harfang.homelinux.org>
>>>> wrote:
>>>>
>>>> > Hi.
>>>> >
>>>> > Please have a look at
>>>> > https://issues.apache.org/jira/browse/NUMBERS-37
>>>> >
>>>> > Comments, suggestions, objections?
>>>> >
>>>> > Regards,
>>>> > Gilles
>>>> >
>>>> >
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [Numbers] Angle class?
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <ra...@decampo.org>
>> 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
>>> <gi...@harfang.homelinux.org>
>>> wrote:
>>>
>>> > Hi.
>>> >
>>> > Please have a look at
>>> > https://issues.apache.org/jira/browse/NUMBERS-37
>>> >
>>> > Comments, suggestions, objections?
>>> >
>>> > Regards,
>>> > Gilles
>>> >
>>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Gilles <gi...@harfang.homelinux.org>.
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 <ra...@decampo.org>
> 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
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>> > Hi.
>> >
>> > Please have a look at
>> > https://issues.apache.org/jira/browse/NUMBERS-37
>> >
>> > Comments, suggestions, objections?
>> >
>> > Regards,
>> > Gilles
>> >
>> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Numbers] Angle class?
Posted by Amey Jadiye <am...@gmail.com>.
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 <ra...@decampo.org> 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 <gi...@harfang.homelinux.org>
> wrote:
>
> > Hi.
> >
> > Please have a look at
> > https://issues.apache.org/jira/browse/NUMBERS-37
> >
> > Comments, suggestions, objections?
> >
> > Regards,
> > Gilles
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
,Thanks
_____________________
*Amey Jadiye*
(+91 73 87 770 382)
Re: [Numbers] Angle class?
Posted by Raymond DeCampo <ra...@decampo.org>.
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 <gi...@harfang.homelinux.org>
wrote:
> Hi.
>
> Please have a look at
> https://issues.apache.org/jira/browse/NUMBERS-37
>
> Comments, suggestions, objections?
>
> Regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>