[VOTE] New component: Standard math functions

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[VOTE] New component: Standard math functions

Gilles Sadowski
Hello.

This is one of several votes for establishing new Commons components
out of functionality developed inside the "Commons Math" component.

This vote is dedicated to the following functionality:
   Standard mathematical functions (either missing from
"java.lang.Math",
   or faster or more accurate than their counterpart in the JDK) and
   floating point utilities.

The concerned code is the contents of the following classes and
packages:
   org.apache.commons.math4.Field
   org.apache.commons.math4.FieldElement
   org.apache.commons.math4.RealFieldElement
   org.apache.commons.math4.util.FastMath (and helper classes)
   org.apache.commons.math4.util.Precision
   org.apache.commons.math4.util.MathUtils
   org.apache.commons.math4.util.ArithmeticUtils
   org.apache.commons.math4.util.Combinations
   org.apache.commons.math4.util.CombinatoricsUtils
   org.apache.commons.math4.util.ContinuedFraction
   org.apache.commons.math4.dfp
   org.apache.commons.math4.special
located in the "develop" branch of Commons Math:
   
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
   
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop

Notes:
  * This component will have no dependency.
  * Code size: ~13000 lines of code (unit tests not included).
    [Out of which ~6000 lines are literal numbers defined in
    class "FastMathLiteralArrays".]
  * API: stable.  [But some of it should probably be moved into
    an "internal" package.]
  * Estimated minimum Java version: 5

All are welcome to vote, especially potential users of the candidate
component and people who'd like to contribute to it, through user
support,
bug-fixes and enhancements, documentation, release management.

[ ] +1, this would be a valid Commons component.
[ ] -1, this won't be a good Commons component because ...


Thanks,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Artem Barger
On Tue, Jun 21, 2016 at 10:30 PM, Gilles <[hidden email]>
wrote:

> Hello.
>
> This is one of several votes for establishing new Commons components
> out of functionality developed inside the "Commons Math" component.
>
> This vote is dedicated to the following functionality:
>   Standard mathematical functions (either missing from "java.lang.Math",
>   or faster or more accurate than their counterpart in the JDK) and
>   floating point utilities.
>
> The concerned code is the contents of the following classes and packages:
>   org.apache.commons.math4.Field
>   org.apache.commons.math4.FieldElement
>   org.apache.commons.math4.RealFieldElement
>   org.apache.commons.math4.util.FastMath (and helper classes)
>   org.apache.commons.math4.util.Precision
>   org.apache.commons.math4.util.MathUtils
>   org.apache.commons.math4.util.ArithmeticUtils
>   org.apache.commons.math4.util.Combinations
>   org.apache.commons.math4.util.CombinatoricsUtils
>   org.apache.commons.math4.util.ContinuedFraction
>   org.apache.commons.math4.dfp
>   org.apache.commons.math4.special
> located in the "develop" branch of Commons Math:
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop


​What about o.a.c.m.fraction package? IMO it fits well into the list above.​


>
> Notes:
>  * This component will have no dependency.
>  * Code size: ~13000 lines of code (unit tests not included).
>    [Out of which ~6000 lines are literal numbers defined in
>    class "FastMathLiteralArrays".]
>  * API: stable.  [But some of it should probably be moved into
>    an "internal" package.]
>  * Estimated minimum Java version: 5
>
> All are welcome to vote, especially potential users of the candidate
> component and people who'd like to contribute to it, through user support,
> bug-fixes and enhancements, documentation, release management.
>
> [ ] +1, this would be a valid Commons component.
> [ ] -1, this won't be a good Commons component because ...
>
>
​Not sure whenever my voice can be counted here.

+1.

Best regrads,
            Artem Barger.​
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
Le 21/06/2016 à 21:30, Gilles a écrit :

> This vote is dedicated to the following functionality:
>   Standard mathematical functions (either missing from "java.lang.Math",
>   or faster or more accurate than their counterpart in the JDK) and
>   floating point utilities.

-0, I don't feel the scope is well defined enough to become a component.
I don't know the commons-math API well, but intuitively these packages
look like what I would expect to remain in the base commons-math
component after splitting the specialized components.

Emmanuel Bourg



signature.asc (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Benedikt Ritter-4
In reply to this post by Gilles Sadowski
+/- 0 I'm unsure.

We already have some Math code in Commons Lang. Maybe this code would fit
into o.a.c.lang3.math ?
OTOH it's a big codebase, it may make sense to make a separate component
out of it.
The scope is pretty math centric. So a Math TLP may be a better home for
this.

Benedikt

Gilles <[hidden email]> schrieb am Di., 21. Juni 2016 um
21:30 Uhr:

> Hello.
>
> This is one of several votes for establishing new Commons components
> out of functionality developed inside the "Commons Math" component.
>
> This vote is dedicated to the following functionality:
>    Standard mathematical functions (either missing from
> "java.lang.Math",
>    or faster or more accurate than their counterpart in the JDK) and
>    floating point utilities.
>
> The concerned code is the contents of the following classes and
> packages:
>    org.apache.commons.math4.Field
>    org.apache.commons.math4.FieldElement
>    org.apache.commons.math4.RealFieldElement
>    org.apache.commons.math4.util.FastMath (and helper classes)
>    org.apache.commons.math4.util.Precision
>    org.apache.commons.math4.util.MathUtils
>    org.apache.commons.math4.util.ArithmeticUtils
>    org.apache.commons.math4.util.Combinations
>    org.apache.commons.math4.util.CombinatoricsUtils
>    org.apache.commons.math4.util.ContinuedFraction
>    org.apache.commons.math4.dfp
>    org.apache.commons.math4.special
> located in the "develop" branch of Commons Math:
>
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
>
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop
>
> Notes:
>   * This component will have no dependency.
>   * Code size: ~13000 lines of code (unit tests not included).
>     [Out of which ~6000 lines are literal numbers defined in
>     class "FastMathLiteralArrays".]
>   * API: stable.  [But some of it should probably be moved into
>     an "internal" package.]
>   * Estimated minimum Java version: 5
>
> All are welcome to vote, especially potential users of the candidate
> component and people who'd like to contribute to it, through user
> support,
> bug-fixes and enhancements, documentation, release management.
>
> [ ] +1, this would be a valid Commons component.
> [ ] -1, this won't be a good Commons component because ...
>
>
> Thanks,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Gilles Sadowski
On Wed, 22 Jun 2016 10:45:33 +0000, Benedikt Ritter wrote:
> +/- 0 I'm unsure.
>
> We already have some Math code in Commons Lang. Maybe this code would
> fit
> into o.a.c.lang3.math ?

In principle, yes, but I'd be wary of a big codebase that becomes less
and less focused.

I think that whatever is a enhancement/extension/generalization of some
JDK functionality is worth a component.

By your line of reasoning, shouldn't "crypto" have been included in as
"o.a.c.lang3.crypto"?

In the "math" case, we enhance tools from "java.lang.Math" (drop-in
remplacement with higher accuracy was the purpose of "FastMath"), then
generalize to unlimited precision ("dfp") and extend with common
(really!)
functions not available[1] in the JDK (combinations, factorial log,
error
functions).

As said, this is all *stable* API (after the necessary adaptation to a
new component) which the Commons PMC would be totally justified to
enforce.

And the main architect and maintainer of a lot of this code is Sebb;
which IMO is a pretty strong argument to have it here.

> OTOH it's a big codebase, it may make sense to make a separate
> component
> out of it.

Exactly.

> The scope is pretty math centric. So a Math TLP may be a better home
> for
> this.

Many, many things are "math-centric"; it certainly does not mean they
should belong to the same TLP.  Trying to set up an "all math" TLP is
doomed to fail like CM did (because the same little turfs will appear,
leading to a growing disparity in the development).[2]


Regards,
Gilles

[1] Or not yet, for older Java versions.
[2] This is all provable from the archives and commit log (but nobody
     will take the time to do the research...).

> Benedikt
>
> Gilles <[hidden email]> schrieb am Di., 21. Juni 2016
> um
> 21:30 Uhr:
>
>> Hello.
>>
>> This is one of several votes for establishing new Commons components
>> out of functionality developed inside the "Commons Math" component.
>>
>> This vote is dedicated to the following functionality:
>>    Standard mathematical functions (either missing from
>> "java.lang.Math",
>>    or faster or more accurate than their counterpart in the JDK) and
>>    floating point utilities.
>>
>> The concerned code is the contents of the following classes and
>> packages:
>>    org.apache.commons.math4.Field
>>    org.apache.commons.math4.FieldElement
>>    org.apache.commons.math4.RealFieldElement
>>    org.apache.commons.math4.util.FastMath (and helper classes)
>>    org.apache.commons.math4.util.Precision
>>    org.apache.commons.math4.util.MathUtils
>>    org.apache.commons.math4.util.ArithmeticUtils
>>    org.apache.commons.math4.util.Combinations
>>    org.apache.commons.math4.util.CombinatoricsUtils
>>    org.apache.commons.math4.util.ContinuedFraction
>>    org.apache.commons.math4.dfp
>>    org.apache.commons.math4.special
>> located in the "develop" branch of Commons Math:
>>
>>
>>
>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
>>
>>
>>
>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop
>>
>> Notes:
>>   * This component will have no dependency.
>>   * Code size: ~13000 lines of code (unit tests not included).
>>     [Out of which ~6000 lines are literal numbers defined in
>>     class "FastMathLiteralArrays".]
>>   * API: stable.  [But some of it should probably be moved into
>>     an "internal" package.]
>>   * Estimated minimum Java version: 5
>>
>> All are welcome to vote, especially potential users of the candidate
>> component and people who'd like to contribute to it, through user
>> support,
>> bug-fixes and enhancements, documentation, release management.
>>
>> [ ] +1, this would be a valid Commons component.
>> [ ] -1, this won't be a good Commons component because ...
>>
>>
>> Thanks,
>> Gilles
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Stian Soiland-Reyes
In reply to this post by Gilles Sadowski
+0

The big mix of stuff here makes it feel like Commons Math Lite, so I would
not decide on this before the Math TLP/Incubator route is settled (or
abandoned).

On 21 Jun 2016 8:30 p.m., "Gilles" <[hidden email]> wrote:

> Hello.
>
> This is one of several votes for establishing new Commons components
> out of functionality developed inside the "Commons Math" component.
>
> This vote is dedicated to the following functionality:
>   Standard mathematical functions (either missing from "java.lang.Math",
>   or faster or more accurate than their counterpart in the JDK) and
>   floating point utilities.
>
> The concerned code is the contents of the following classes and packages:
>   org.apache.commons.math4.Field
>   org.apache.commons.math4.FieldElement
>   org.apache.commons.math4.RealFieldElement
>   org.apache.commons.math4.util.FastMath (and helper classes)
>   org.apache.commons.math4.util.Precision
>   org.apache.commons.math4.util.MathUtils
>   org.apache.commons.math4.util.ArithmeticUtils
>   org.apache.commons.math4.util.Combinations
>   org.apache.commons.math4.util.CombinatoricsUtils
>   org.apache.commons.math4.util.ContinuedFraction
>   org.apache.commons.math4.dfp
>   org.apache.commons.math4.special
> located in the "develop" branch of Commons Math:
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
>
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop
>
> Notes:
>  * This component will have no dependency.
>  * Code size: ~13000 lines of code (unit tests not included).
>    [Out of which ~6000 lines are literal numbers defined in
>    class "FastMathLiteralArrays".]
>  * API: stable.  [But some of it should probably be moved into
>    an "internal" package.]
>  * Estimated minimum Java version: 5
>
> All are welcome to vote, especially potential users of the candidate
> component and people who'd like to contribute to it, through user support,
> bug-fixes and enhancements, documentation, release management.
>
> [ ] +1, this would be a valid Commons component.
> [ ] -1, this won't be a good Commons component because ...
>
>
> Thanks,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Gilles Sadowski
On Sat, 25 Jun 2016 15:01:14 +0100, Stian Soiland-Reyes wrote:
> +0
>
> The big mix of stuff here makes it feel like Commons Math Lite,

Hmm, no; it's certainly more akin to... Commons Lang, but
more focused (on numerical utilities) and much leaner!

Actually, the big code chunk is, by far, "FastMath", which
is an almost drop-in replacement for the JDK's "Math" class.
It is thus very high on the scale of "stability" (read: API
is as stable as the JDK).

The lines of code counts are:
  FastMath (and helper): ~8800
  dfp:                   ~2800
  *all the rest*:        ~2350

The common denominator is: very low-level utilities (static
methods, no OO!).

Maintenance cost of this component should be very low.

Also, its contents is sometimes _used_ by other parts of CM,
but it is also, from a certain POV, much more specialized: the
"unlimited" precision functionality is not needed by applications
in domains where either the accuracy (of the "input") is much
lower than "double" precision or the performance hit incurred is
not worth it.

In "all the rest", there are many useful little things that are
also pretty much in a "final" state (review is certainly welcome
before release).

In fact, this component would really deserve the name "Commons
Math"!  [While the actual "Commons Math" is a hodgepodge of
codes that should have belonged to different modules.]

Gilles


> so I would
> not decide on this before the Math TLP/Incubator route is settled (or
> abandoned).
>
> On 21 Jun 2016 8:30 p.m., "Gilles" <[hidden email]>
> wrote:
>
>> Hello.
>>
>> This is one of several votes for establishing new Commons components
>> out of functionality developed inside the "Commons Math" component.
>>
>> This vote is dedicated to the following functionality:
>>   Standard mathematical functions (either missing from
>> "java.lang.Math",
>>   or faster or more accurate than their counterpart in the JDK) and
>>   floating point utilities.
>>
>> The concerned code is the contents of the following classes and
>> packages:
>>   org.apache.commons.math4.Field
>>   org.apache.commons.math4.FieldElement
>>   org.apache.commons.math4.RealFieldElement
>>   org.apache.commons.math4.util.FastMath (and helper classes)
>>   org.apache.commons.math4.util.Precision
>>   org.apache.commons.math4.util.MathUtils
>>   org.apache.commons.math4.util.ArithmeticUtils
>>   org.apache.commons.math4.util.Combinations
>>   org.apache.commons.math4.util.CombinatoricsUtils
>>   org.apache.commons.math4.util.ContinuedFraction
>>   org.apache.commons.math4.dfp
>>   org.apache.commons.math4.special
>> located in the "develop" branch of Commons Math:
>>
>>
>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
>>
>>
>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop
>>
>> Notes:
>>  * This component will have no dependency.
>>  * Code size: ~13000 lines of code (unit tests not included).
>>    [Out of which ~6000 lines are literal numbers defined in
>>    class "FastMathLiteralArrays".]
>>  * API: stable.  [But some of it should probably be moved into
>>    an "internal" package.]
>>  * Estimated minimum Java version: 5
>>
>> All are welcome to vote, especially potential users of the candidate
>> component and people who'd like to contribute to it, through user
>> support,
>> bug-fixes and enhancements, documentation, release management.
>>
>> [ ] +1, this would be a valid Commons component.
>> [ ] -1, this won't be a good Commons component because ...
>>
>>
>> Thanks,
>> Gilles
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

garydgregory
One could argue that since Java has java.util.Random, Commons Lang could
include a random package.

Gary
On Jun 25, 2016 9:06 AM, "Gilles" <[hidden email]> wrote:

> On Sat, 25 Jun 2016 15:01:14 +0100, Stian Soiland-Reyes wrote:
>
>> +0
>>
>> The big mix of stuff here makes it feel like Commons Math Lite,
>>
>
> Hmm, no; it's certainly more akin to... Commons Lang, but
> more focused (on numerical utilities) and much leaner!
>
> Actually, the big code chunk is, by far, "FastMath", which
> is an almost drop-in replacement for the JDK's "Math" class.
> It is thus very high on the scale of "stability" (read: API
> is as stable as the JDK).
>
> The lines of code counts are:
>  FastMath (and helper): ~8800
>  dfp:                   ~2800
>  *all the rest*:        ~2350
>
> The common denominator is: very low-level utilities (static
> methods, no OO!).
>
> Maintenance cost of this component should be very low.
>
> Also, its contents is sometimes _used_ by other parts of CM,
> but it is also, from a certain POV, much more specialized: the
> "unlimited" precision functionality is not needed by applications
> in domains where either the accuracy (of the "input") is much
> lower than "double" precision or the performance hit incurred is
> not worth it.
>
> In "all the rest", there are many useful little things that are
> also pretty much in a "final" state (review is certainly welcome
> before release).
>
> In fact, this component would really deserve the name "Commons
> Math"!  [While the actual "Commons Math" is a hodgepodge of
> codes that should have belonged to different modules.]
>
> Gilles
>
>
> so I would
>> not decide on this before the Math TLP/Incubator route is settled (or
>> abandoned).
>>
>> On 21 Jun 2016 8:30 p.m., "Gilles" <[hidden email]> wrote:
>>
>> Hello.
>>>
>>> This is one of several votes for establishing new Commons components
>>> out of functionality developed inside the "Commons Math" component.
>>>
>>> This vote is dedicated to the following functionality:
>>>   Standard mathematical functions (either missing from "java.lang.Math",
>>>   or faster or more accurate than their counterpart in the JDK) and
>>>   floating point utilities.
>>>
>>> The concerned code is the contents of the following classes and packages:
>>>   org.apache.commons.math4.Field
>>>   org.apache.commons.math4.FieldElement
>>>   org.apache.commons.math4.RealFieldElement
>>>   org.apache.commons.math4.util.FastMath (and helper classes)
>>>   org.apache.commons.math4.util.Precision
>>>   org.apache.commons.math4.util.MathUtils
>>>   org.apache.commons.math4.util.ArithmeticUtils
>>>   org.apache.commons.math4.util.Combinations
>>>   org.apache.commons.math4.util.CombinatoricsUtils
>>>   org.apache.commons.math4.util.ContinuedFraction
>>>   org.apache.commons.math4.dfp
>>>   org.apache.commons.math4.special
>>> located in the "develop" branch of Commons Math:
>>>
>>>
>>>
>>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/util;h=c54f99f943f758e43ebeb54d8771a6ef6516d283;hb=refs/heads/develop
>>>
>>>
>>>
>>> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/special;h=b8fb8b1f6e29a549d0716c866939e074525246a1;hb=refs/heads/develop
>>>
>>> Notes:
>>>  * This component will have no dependency.
>>>  * Code size: ~13000 lines of code (unit tests not included).
>>>    [Out of which ~6000 lines are literal numbers defined in
>>>    class "FastMathLiteralArrays".]
>>>  * API: stable.  [But some of it should probably be moved into
>>>    an "internal" package.]
>>>  * Estimated minimum Java version: 5
>>>
>>> All are welcome to vote, especially potential users of the candidate
>>> component and people who'd like to contribute to it, through user
>>> support,
>>> bug-fixes and enhancements, documentation, release management.
>>>
>>> [ ] +1, this would be a valid Commons component.
>>> [ ] -1, this won't be a good Commons component because ...
>>>
>>>
>>> Thanks,
>>> Gilles
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

jochen-2
On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory <[hidden email]> wrote:
> One could argue that since Java has java.util.Random, Commons Lang could
> include a random package.

For the same reason, [io] might be moved to [lang], too.

Jochen


--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Gilles Sadowski
On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
> <[hidden email]> wrote:
>> One could argue that since Java has java.util.Random, Commons Lang
>> could
>> include a random package.
>
> For the same reason, [io] might be moved to [lang], too.

And [compress], [crypto], [imaging], [dbutils], [logging], [net].
;-}

Gilles


>
> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Rob Tompkins


> On Jun 26, 2016, at 11:21 AM, Gilles <[hidden email]> wrote:
>
>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory <[hidden email]> wrote:
>>> One could argue that since Java has java.util.Random, Commons Lang could
>>> include a random package.

Yes, and it feels like an even more appropriate place for org.apache.commons.math3.util.FastMath (and maybe associated classes) due to the location of java.lang.Math.

-Rob

>>
>> For the same reason, [io] might be moved to [lang], too.
>
> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
> ;-}
>
> Gilles
>
>
>>
>> Jochen
>
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Gilles Sadowski
On Sun, 26 Jun 2016 16:13:06 -0400, Rob Tompkins wrote:

>> On Jun 26, 2016, at 11:21 AM, Gilles <[hidden email]>
>> wrote:
>>
>>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
>>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
>>>> <[hidden email]> wrote:
>>>> One could argue that since Java has java.util.Random, Commons Lang
>>>> could
>>>> include a random package.
>
> Yes, and it feels like an even more appropriate place for
> org.apache.commons.math3.util.FastMath (and maybe associated classes)
> due to the location of java.lang.Math.

I don't think so.
I'm in favour of "small" components.

Take into account that Commons Lang is probably less stable
than "FastMath": CL's top-level package name is now "lang3"
whereas this functionality would be located in a package whose
name would never change.

Also, since the JDK itself is going to be "modular", it is a
bit odd to go in the opposite direction.


Gilles

> -Rob
>
>>>
>>> For the same reason, [io] might be moved to [lang], too.
>>
>> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
>> ;-}
>>
>> Gilles
>>
>>
>>>
>>> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

venkatesha m-2
Does this use Java 8?

    On Monday, 27 June 2016 2:20 AM, Gilles <[hidden email]> wrote:
 

 On Sun, 26 Jun 2016 16:13:06 -0400, Rob Tompkins wrote:

>> On Jun 26, 2016, at 11:21 AM, Gilles <[hidden email]>
>> wrote:
>>
>>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
>>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
>>>> <[hidden email]> wrote:
>>>> One could argue that since Java has java.util.Random, Commons Lang
>>>> could
>>>> include a random package.
>
> Yes, and it feels like an even more appropriate place for
> org.apache.commons.math3.util.FastMath (and maybe associated classes)
> due to the location of java.lang.Math.

I don't think so.
I'm in favour of "small" components.

Take into account that Commons Lang is probably less stable
than "FastMath": CL's top-level package name is now "lang3"
whereas this functionality would be located in a package whose
name would never change.

Also, since the JDK itself is going to be "modular", it is a
bit odd to go in the opposite direction.


Gilles

> -Rob
>
>>>
>>> For the same reason, [io] might be moved to [lang], too.
>>
>> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
>> ;-}
>>
>> Gilles
>>
>>
>>>
>>> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



   
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Gilles Sadowski
On Mon, 27 Jun 2016 03:55:35 +0000 (UTC), venkatesha m wrote:
> Does this use Java 8?

What is "this"?

If you want to discuss (rather than vote), please start a new
thread.

Thank you,
Gilles


>     On Monday, 27 June 2016 2:20 AM, Gilles
> <[hidden email]> wrote:
>
>
>  On Sun, 26 Jun 2016 16:13:06 -0400, Rob Tompkins wrote:
>>> On Jun 26, 2016, at 11:21 AM, Gilles <[hidden email]>
>>> wrote:
>>>
>>>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
>>>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
>>>>> <[hidden email]> wrote:
>>>>> One could argue that since Java has java.util.Random, Commons
>>>>> Lang
>>>>> could
>>>>> include a random package.
>>
>> Yes, and it feels like an even more appropriate place for
>> org.apache.commons.math3.util.FastMath (and maybe associated
>> classes)
>> due to the location of java.lang.Math.
>
> I don't think so.
> I'm in favour of "small" components.
>
> Take into account that Commons Lang is probably less stable
> than "FastMath": CL's top-level package name is now "lang3"
> whereas this functionality would be located in a package whose
> name would never change.
>
> Also, since the JDK itself is going to be "modular", it is a
> bit odd to go in the opposite direction.
>
>
> Gilles
>
>> -Rob
>>
>>>>
>>>> For the same reason, [io] might be moved to [lang], too.
>>>
>>> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
>>> ;-}
>>>
>>> Gilles
>>>
>>>
>>>>
>>>> Jochen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Rob Tompkins
+1 [contributor, not committer]

> On Jun 27, 2016, at 6:23 AM, Gilles <[hidden email]> wrote:
>
> On Mon, 27 Jun 2016 03:55:35 +0000 (UTC), venkatesha m wrote:
>> Does this use Java 8?
>
> What is "this"?
>
> If you want to discuss (rather than vote), please start a new
> thread.
>
> Thank you,
> Gilles
>
>
>>    On Monday, 27 June 2016 2:20 AM, Gilles
>> <[hidden email]> wrote:
>>
>>
>> On Sun, 26 Jun 2016 16:13:06 -0400, Rob Tompkins wrote:
>>>> On Jun 26, 2016, at 11:21 AM, Gilles <[hidden email]>
>>>> wrote:
>>>>
>>>>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
>>>>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
>>>>>> <[hidden email]> wrote:
>>>>>> One could argue that since Java has java.util.Random, Commons Lang
>>>>>> could
>>>>>> include a random package.
>>>
>>> Yes, and it feels like an even more appropriate place for
>>> org.apache.commons.math3.util.FastMath (and maybe associated classes)
>>> due to the location of java.lang.Math.
>>
>> I don't think so.
>> I'm in favour of "small" components.
>>
>> Take into account that Commons Lang is probably less stable
>> than "FastMath": CL's top-level package name is now "lang3"
>> whereas this functionality would be located in a package whose
>> name would never change.
>>
>> Also, since the JDK itself is going to be "modular", it is a
>> bit odd to go in the opposite direction.
>>
>>
>> Gilles
>>
>>> -Rob
>>>
>>>>>
>>>>> For the same reason, [io] might be moved to [lang], too.
>>>>
>>>> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
>>>> ;-}
>>>>
>>>> Gilles
>>>>
>>>>
>>>>>
>>>>> Jochen
>
>
> ---------------------------------------------------------------------
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

Artem Barger
+1 [contributor]

Best regards,
                      Artem Barger.

On Fri, Jul 1, 2016 at 3:34 PM, Rob Tompkins <[hidden email]> wrote:

> +1 [contributor, not committer]
>
> > On Jun 27, 2016, at 6:23 AM, Gilles <[hidden email]>
> wrote:
> >
> > On Mon, 27 Jun 2016 03:55:35 +0000 (UTC), venkatesha m wrote:
> >> Does this use Java 8?
> >
> > What is "this"?
> >
> > If you want to discuss (rather than vote), please start a new
> > thread.
> >
> > Thank you,
> > Gilles
> >
> >
> >>    On Monday, 27 June 2016 2:20 AM, Gilles
> >> <[hidden email]> wrote:
> >>
> >>
> >> On Sun, 26 Jun 2016 16:13:06 -0400, Rob Tompkins wrote:
> >>>> On Jun 26, 2016, at 11:21 AM, Gilles <[hidden email]>
> >>>> wrote:
> >>>>
> >>>>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
> >>>>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
> >>>>>> <[hidden email]> wrote:
> >>>>>> One could argue that since Java has java.util.Random, Commons Lang
> >>>>>> could
> >>>>>> include a random package.
> >>>
> >>> Yes, and it feels like an even more appropriate place for
> >>> org.apache.commons.math3.util.FastMath (and maybe associated classes)
> >>> due to the location of java.lang.Math.
> >>
> >> I don't think so.
> >> I'm in favour of "small" components.
> >>
> >> Take into account that Commons Lang is probably less stable
> >> than "FastMath": CL's top-level package name is now "lang3"
> >> whereas this functionality would be located in a package whose
> >> name would never change.
> >>
> >> Also, since the JDK itself is going to be "modular", it is a
> >> bit odd to go in the opposite direction.
> >>
> >>
> >> Gilles
> >>
> >>> -Rob
> >>>
> >>>>>
> >>>>> For the same reason, [io] might be moved to [lang], too.
> >>>>
> >>>> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
> >>>> ;-}
> >>>>
> >>>> Gilles
> >>>>
> >>>>
> >>>>>
> >>>>> Jochen
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] New component: Standard math functions

venkatesha m-2
+1

    On Saturday, 2 July 2016 1:27 AM, Artem Barger <[hidden email]> wrote:
 

 +1 [contributor]

Best regards,
                      Artem Barger.

On Fri, Jul 1, 2016 at 3:34 PM, Rob Tompkins <[hidden email]> wrote:

> +1 [contributor, not committer]
>
> > On Jun 27, 2016, at 6:23 AM, Gilles <[hidden email]>
> wrote:
> >
> > On Mon, 27 Jun 2016 03:55:35 +0000 (UTC), venkatesha m wrote:
> >> Does this use Java 8?
> >
> > What is "this"?
> >
> > If you want to discuss (rather than vote), please start a new
> > thread.
> >
> > Thank you,
> > Gilles
> >
> >
> >>    On Monday, 27 June 2016 2:20 AM, Gilles
> >> <[hidden email]> wrote:
> >>
> >>
> >> On Sun, 26 Jun 2016 16:13:06 -0400, Rob Tompkins wrote:
> >>>> On Jun 26, 2016, at 11:21 AM, Gilles <[hidden email]>
> >>>> wrote:
> >>>>
> >>>>> On Sun, 26 Jun 2016 12:35:38 +0200, Jochen Wiedmann wrote:
> >>>>>> On Sat, Jun 25, 2016 at 9:00 PM, Gary Gregory
> >>>>>> <[hidden email]> wrote:
> >>>>>> One could argue that since Java has java.util.Random, Commons Lang
> >>>>>> could
> >>>>>> include a random package.
> >>>
> >>> Yes, and it feels like an even more appropriate place for
> >>> org.apache.commons.math3.util.FastMath (and maybe associated classes)
> >>> due to the location of java.lang.Math.
> >>
> >> I don't think so.
> >> I'm in favour of "small" components.
> >>
> >> Take into account that Commons Lang is probably less stable
> >> than "FastMath": CL's top-level package name is now "lang3"
> >> whereas this functionality would be located in a package whose
> >> name would never change.
> >>
> >> Also, since the JDK itself is going to be "modular", it is a
> >> bit odd to go in the opposite direction.
> >>
> >>
> >> Gilles
> >>
> >>> -Rob
> >>>
> >>>>>
> >>>>> For the same reason, [io] might be moved to [lang], too.
> >>>>
> >>>> And [compress], [crypto], [imaging], [dbutils], [logging], [net].
> >>>> ;-}
> >>>>
> >>>> Gilles
> >>>>
> >>>>
> >>>>>
> >>>>> Jochen
> >
> >
> > ---------------------------------------------------------------------
> > 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]
>
>