You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Emmanuel Bourg <eb...@apache.org> on 2016/09/27 10:53:33 UTC
Re: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG")
Le 27/09/2016 � 01:14, Gilles a �crit :
>>> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
>>
>> This should go in the ArrayUtils class of commons-lang, with a
>> java.util.Random parameter.
>
> I don't get that.
> The idea is to parameterize the utilities with a "UniformRandomProvider"
> instance.
My suggestion is to add two methods to ArrayUtils in commons-lang for
each primitive type and Object (and maybe a couple more if we want to
shuffle only a subset of the array):
ArraysUtils.shuffle(Object[] array)
ArraysUtils.shuffle(Object[] array, java.util.Random rnd)
And if we want to shuffle with a random generator from commons-rng, we
simply convert the UniformRandomProvider into a java.util.Random using
the adapter:
RandomProvider rng = RandomSource.create(...);
ArraysUtils.shuffle(array, new JDKRandomAdapter(rng));
or
RandomProvider rng = RandomSource.create(...);
ArraysUtils.shuffle(array, rng.asRandom());
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gary Gregory <ga...@gmail.com>.
I would expect that we provide implementations of this new interface for
all JRE random classes.
On Wed, Sep 28, 2016 at 7:55 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:
>
>> On Wed, Sep 28, 2016 at 1:40 PM, Gilles <gi...@harfang.homelinux.org>
>> wrote:
>>
>> If not, then random utilities are not best located in Commons Lang,
>>> because indeed the no-dep requirement forces you to go through
>>> "java.util.Random" which is bad (TM) for several reasons, mentioned
>>> here, there, and everywhere.
>>>
>>
>> I agree that RNG could be removed from CL (Binary compatibility
>> considerations left aside). However, rather than introducing
>> unnecessary dependencies, one would instead use an RNG interface, with
>> an ovious default implementation. In other words, if "Joe Average
>> Random" (aka Gilles) wants to use Commons RNG, he's perfectly capable
>> to do so.
>>
>>
> Do you mean that CL must define its own interface, say
>
> interface CommonsLangRandom {
> int nextInt();
> long nextong();
> double nextDouble();
> // and so on.
> }
>
> and that it's up to the user to create the bridge for delegating
> to the library of his choice?
>
> So, in _user_ code:
>
> CommonsLangRandom asCLRandom(final java.util.Random rand) {
> return new CommonsLangRandom() {
> public nextInt() {
> return rand.nextInt();
> }
> }
> }
>
> and/or
>
> CommonsLangRandom asCLRandom(final UniformRandomProvider rand) {
> return new CommonsLangRandom() {
> public nextInt() {
> return rand.nextInt();
> }
> }
> }
>
>
> That's the way how you design low level libraries.
>>
>
> That's seems a good compromise if CL is indeed the low-level
> libray it purports to be.
>
>
> Gilles
>
>
>> Jochen
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [lang] Shuffling arrays
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Sep 28, 2016 at 4:55 PM, Gilles <gi...@harfang.homelinux.org> wrote:
> Do you mean that CL must define its own interface, say
Yes, of course. Btw: Note, that commons-crypto does the same [1].
Jochen
1: https://commons.apache.org/proper/commons-crypto/apidocs/org/apache/commons/crypto/random/CryptoRandom.html
--
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:
> On Wed, Sep 28, 2016 at 1:40 PM, Gilles
> <gi...@harfang.homelinux.org> wrote:
>
>> If not, then random utilities are not best located in Commons Lang,
>> because indeed the no-dep requirement forces you to go through
>> "java.util.Random" which is bad (TM) for several reasons, mentioned
>> here, there, and everywhere.
>
> I agree that RNG could be removed from CL (Binary compatibility
> considerations left aside). However, rather than introducing
> unnecessary dependencies, one would instead use an RNG interface,
> with
> an ovious default implementation. In other words, if "Joe Average
> Random" (aka Gilles) wants to use Commons RNG, he's perfectly capable
> to do so.
>
Do you mean that CL must define its own interface, say
interface CommonsLangRandom {
int nextInt();
long nextong();
double nextDouble();
// and so on.
}
and that it's up to the user to create the bridge for delegating
to the library of his choice?
So, in _user_ code:
CommonsLangRandom asCLRandom(final java.util.Random rand) {
return new CommonsLangRandom() {
public nextInt() {
return rand.nextInt();
}
}
}
and/or
CommonsLangRandom asCLRandom(final UniformRandomProvider rand) {
return new CommonsLangRandom() {
public nextInt() {
return rand.nextInt();
}
}
}
> That's the way how you design low level libraries.
That's seems a good compromise if CL is indeed the low-level
libray it purports to be.
Gilles
>
> Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Sep 28, 2016 at 1:40 PM, Gilles <gi...@harfang.homelinux.org> wrote:
> If not, then random utilities are not best located in Commons Lang,
> because indeed the no-dep requirement forces you to go through
> "java.util.Random" which is bad (TM) for several reasons, mentioned
> here, there, and everywhere.
I agree that RNG could be removed from CL (Binary compatibility
considerations left aside). However, rather than introducing
unnecessary dependencies, one would instead use an RNG interface, with
an ovious default implementation. In other words, if "Joe Average
Random" (aka Gilles) wants to use Commons RNG, he's perfectly capable
to do so.
That's the way how you design low level libraries.
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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 30 Sep 2016 11:34:10 -0500, Matt Sicker wrote:
> I thought he meant that if your code works with either Random or
> SecureRandom, you're doing it wrong. They both have very different
> use
> cases, and the fact that SecureRandom extends Random contributes to
> the
> confusion.
Indeed.
[I should have read the thread up to the top before duplicating your
answer.]
Regards,
Gilles
> On 30 September 2016 at 08:02, Emmanuel Bourg <eb...@apache.org>
> wrote:
>
>> Le 28/09/2016 � 15:28, Gilles a �crit :
>>
>> > Conversely, using "SecureRandom" in place of a deterministic
>> > RNG is only useful in toy applications since the main feature
>> > (of non-secure RNGs) one usually needs is reproducibility.
>>
>> I guess the Tomcat developers will love hearing they are building a
>> toy
>> application :)
>>
>> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/
>> java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>>
>>
>> > [1] Even the Java architects have indirectly acknowledged that,
>> > by having a new random-related class _NOT_ extend "Random"
>> > (allowing them to drop all the cruft brought by it).
>>
>> Are you referring to java.security.SecureRandomSpi not extending
>> java.util.Random? This is merely a mechanism allowing to plug extra
>> implementations, the whole security package is designed around this
>> concept. But users only deal with SecureRandom, which extends
>> Random.
>>
>> Emmanuel Bourg
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Matt Sicker <bo...@gmail.com>.
I thought he meant that if your code works with either Random or
SecureRandom, you're doing it wrong. They both have very different use
cases, and the fact that SecureRandom extends Random contributes to the
confusion.
On 30 September 2016 at 08:02, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 28/09/2016 à 15:28, Gilles a écrit :
>
> > Conversely, using "SecureRandom" in place of a deterministic
> > RNG is only useful in toy applications since the main feature
> > (of non-secure RNGs) one usually needs is reproducibility.
>
> I guess the Tomcat developers will love hearing they are building a toy
> application :)
>
> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/
> java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>
>
> > [1] Even the Java architects have indirectly acknowledged that,
> > by having a new random-related class _NOT_ extend "Random"
> > (allowing them to drop all the cruft brought by it).
>
> Are you referring to java.security.SecureRandomSpi not extending
> java.util.Random? This is merely a mechanism allowing to plug extra
> implementations, the whole security package is designed around this
> concept. But users only deal with SecureRandom, which extends Random.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Matt Sicker <bo...@gmail.com>
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 30 Sep 2016 15:02:40 +0200, Emmanuel Bourg wrote:
> Le 28/09/2016 � 15:28, Gilles a �crit :
>
>> Conversely, using "SecureRandom" in place of a deterministic
>> RNG is only useful in toy applications since the main feature
>> (of non-secure RNGs) one usually needs is reproducibility.
>
> I guess the Tomcat developers will love hearing they are building a
> toy
> application :)
A complete misinterpretation of my sentence.
If an application requires a cryptographically secure generator,
then using (i.e. allowing a user to choose) a deterministic one
might incur a vulnerability.
If an application must generate reproducible results, then
allowing a cryptographically secure generator is a useless
feature.
>
>
> https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
>
>
>> [1] Even the Java architects have indirectly acknowledged that,
>> by having a new random-related class _NOT_ extend "Random"
>> (allowing them to drop all the cruft brought by it).
>
> Are you referring to java.security.SecureRandomSpi not extending
> java.util.Random?
No, "SplittableRandom".
Gilles
> This is merely a mechanism allowing to plug extra
> implementations, the whole security package is designed around this
> concept. But users only deal with SecureRandom, which extends Random.
>
> Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2016 � 15:28, Gilles a �crit :
> Conversely, using "SecureRandom" in place of a deterministic
> RNG is only useful in toy applications since the main feature
> (of non-secure RNGs) one usually needs is reproducibility.
I guess the Tomcat developers will love hearing they are building a toy
application :)
https://github.com/apache/tomcat80/blob/TOMCAT_8_0_37/java/org/apache/catalina/util/SessionIdGeneratorBase.java#L170
> [1] Even the Java architects have indirectly acknowledged that,
> by having a new random-related class _NOT_ extend "Random"
> (allowing them to drop all the cruft brought by it).
Are you referring to java.security.SecureRandomSpi not extending
java.util.Random? This is merely a mechanism allowing to plug extra
implementations, the whole security package is designed around this
concept. But users only deal with SecureRandom, which extends Random.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 28 Sep 2016 13:47:49 +0200, Emmanuel Bourg wrote:
> Le 28/09/2016 � 13:40, Gilles a �crit :
>
>> If not, then random utilities are not best located in Commons Lang,
>> because indeed the no-dep requirement forces you to go through
>> "java.util.Random" which is bad (TM) for several reasons, mentioned
>> here, there, and everywhere.
>
> I agree java.util.Random is suboptimal as an implementation, but it's
> perfectly fine as an interface.
It is not. See the post I've just sent.
> It can be swapped with a
> java.security.SecureRandom if quality matters.
The interchangeability of "Random" and "SecureRandom" is beside
the point.
PRNG for cryptographic use, or not, have different priorities
and requirements.
It is only the most superficial analysis that would consider it
important that "SecureRandom" extends "Random".[1]
An application that would allow either is probably not to be
trusted for anything cryptographic.
Conversely, using "SecureRandom" in place of a deterministic
RNG is only useful in toy applications since the main feature
(of non-secure RNGs) one usually needs is reproducibility.
"SecureRandom" have requirements that are utterly foreign to
deterministic implementations (cf. entropy management).
Also "SecureRandom" can be comparatively slow. Letting users
think that they can use them interchangeably is bad advice.
Gilles
[1] Even the Java architects have indirectly acknowledged that,
by having a new random-related class _NOT_ extend "Random"
(allowing them to drop all the cruft brought by it).
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2016 � 13:40, Gilles a �crit :
> If not, then random utilities are not best located in Commons Lang,
> because indeed the no-dep requirement forces you to go through
> "java.util.Random" which is bad (TM) for several reasons, mentioned
> here, there, and everywhere.
I agree java.util.Random is suboptimal as an implementation, but it's
perfectly fine as an interface. It can be swapped with a
java.security.SecureRandom if quality matters.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 27 Sep 2016 18:41:59 -0700, Gary Gregory wrote:
> +1: [lang] is a low-level library, which should not have any deps.
This is fine as a requirement.
But then why don't you draw all the conclusions from that, including
that its scope must be limited, lest the goal is for CL to contain
all the Java code in the world?
If not, then random utilities are not best located in Commons Lang,
because indeed the no-dep requirement forces you to go through
"java.util.Random" which is bad (TM) for several reasons, mentioned
here, there, and everywhere.
Gilles
> Gary
>
> On Tue, Sep 27, 2016 at 5:55 PM, Brent Worden
> <br...@gmail.com>
> wrote:
>
>> There are no good reasons for a component such as commons-lang to
>> have any
>> runtime dependencies beside Java itself. The commons-lang install
>> base is
>> enormous with very diverse usage patterns. Having it coupled to
>> another
>> libraries, regardless of the maintainer, invites all kinds of
>> classloading
>> problems when those libraries have different release cadences.
>>
>> Using java.util.Random as a bridge between commons-lang and
>> commons-rng is
>> a very good solution. It allows for UniformRandomProvider instances
>> to be
>> used by commons-lang by simply adapting the providers to
>> java.util.Random
>> instances. The gives the users of commons-lang the ability to use
>> the RNG
>> of their choosing while allowing them to update the components
>> independently of one another to avoid compatibility problems. This
>> give
>> the components high cohesion in that they can easily be used
>> together and
>> low coupling in that they are only bound via a shared, never
>> changing API.
>>
>> Brent
>>
>> On Tue, Sep 27, 2016 at 11:36 AM, Gilles
>> <gi...@harfang.homelinux.org>
>> wrote:
>>
>> > On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
>> >
>> >> Le 27/09/2016 � 13:22, Gilles a �crit :
>> >>
>> >> I (strongly) suggest
>> >>>
>> >>> ArraysUtils.shuffle(Object[] array,
>> o.a.c.rng.UniformRandomProvider
>> >>> rnd)
>> >>>
>> >>
>> >> That's not possible, because we don't want to add external
>> dependencies
>> >> to commons-lang.
>> >>
>> >
>> > I mistakenly thought that your examples (cf. uncut previous post)
>> meant
>> > that this CM-alike tradition was coming to an end...
>> >
>> > Anyway, assuming there are still good reasons for CL to not have
>> > dependencies[1], it is then all the more interesting that
>> utilities
>> > based on RNGs should have their own component.
>> >
>> > CL would benefit (reduced codebase reduces the maintenance cost)
>> > and users would benefit (from using better generators).
>> >
>> > Moreover, the default RNG should be a good one, i.e. not
>> >>> "java.util.Random".
>> >>>
>> >>
>> >> Using java.util.Random by default is good enough, and it's
>> consistent
>> >> with Collections.shuffle():
>> >>
>> >>
>> >> http://docs.oracle.com/javase/8/docs/api/java/util/Collectio
>> >> ns.html#shuffle-java.util.List-
>> >>
>> >
>> > Well, of course, the JDK utilities use the JDK's RNG.
>> >
>> > That doesn't mean that Apache should do the same, or spread bad
>> > practice:
>> > http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
>> > (see page 2 about "java.util.Random").
>> >
>> > Gilles
>> >
>> > [1] Even if those would be in our total control!
>> >
>> >
>> >
>> >> Emmanuel Bourg
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > 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: [lang] Shuffling arrays
Posted by Gary Gregory <ga...@gmail.com>.
+1: [lang] is a low-level library, which should not have any deps.
Gary
On Tue, Sep 27, 2016 at 5:55 PM, Brent Worden <br...@gmail.com>
wrote:
> There are no good reasons for a component such as commons-lang to have any
> runtime dependencies beside Java itself. The commons-lang install base is
> enormous with very diverse usage patterns. Having it coupled to another
> libraries, regardless of the maintainer, invites all kinds of classloading
> problems when those libraries have different release cadences.
>
> Using java.util.Random as a bridge between commons-lang and commons-rng is
> a very good solution. It allows for UniformRandomProvider instances to be
> used by commons-lang by simply adapting the providers to java.util.Random
> instances. The gives the users of commons-lang the ability to use the RNG
> of their choosing while allowing them to update the components
> independently of one another to avoid compatibility problems. This give
> the components high cohesion in that they can easily be used together and
> low coupling in that they are only bound via a shared, never changing API.
>
> Brent
>
> On Tue, Sep 27, 2016 at 11:36 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
> > On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
> >
> >> Le 27/09/2016 à 13:22, Gilles a écrit :
> >>
> >> I (strongly) suggest
> >>>
> >>> ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider
> >>> rnd)
> >>>
> >>
> >> That's not possible, because we don't want to add external dependencies
> >> to commons-lang.
> >>
> >
> > I mistakenly thought that your examples (cf. uncut previous post) meant
> > that this CM-alike tradition was coming to an end...
> >
> > Anyway, assuming there are still good reasons for CL to not have
> > dependencies[1], it is then all the more interesting that utilities
> > based on RNGs should have their own component.
> >
> > CL would benefit (reduced codebase reduces the maintenance cost)
> > and users would benefit (from using better generators).
> >
> > Moreover, the default RNG should be a good one, i.e. not
> >>> "java.util.Random".
> >>>
> >>
> >> Using java.util.Random by default is good enough, and it's consistent
> >> with Collections.shuffle():
> >>
> >>
> >> http://docs.oracle.com/javase/8/docs/api/java/util/Collectio
> >> ns.html#shuffle-java.util.List-
> >>
> >
> > Well, of course, the JDK utilities use the JDK's RNG.
> >
> > That doesn't mean that Apache should do the same, or spread bad
> > practice:
> > http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
> > (see page 2 about "java.util.Random").
> >
> > Gilles
> >
> > [1] Even if those would be in our total control!
> >
> >
> >
> >> Emmanuel Bourg
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [lang] Shuffling arrays
Posted by Brent Worden <br...@gmail.com>.
There are no good reasons for a component such as commons-lang to have any
runtime dependencies beside Java itself. The commons-lang install base is
enormous with very diverse usage patterns. Having it coupled to another
libraries, regardless of the maintainer, invites all kinds of classloading
problems when those libraries have different release cadences.
Using java.util.Random as a bridge between commons-lang and commons-rng is
a very good solution. It allows for UniformRandomProvider instances to be
used by commons-lang by simply adapting the providers to java.util.Random
instances. The gives the users of commons-lang the ability to use the RNG
of their choosing while allowing them to update the components
independently of one another to avoid compatibility problems. This give
the components high cohesion in that they can easily be used together and
low coupling in that they are only bound via a shared, never changing API.
Brent
On Tue, Sep 27, 2016 at 11:36 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
>
>> Le 27/09/2016 à 13:22, Gilles a écrit :
>>
>> I (strongly) suggest
>>>
>>> ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider
>>> rnd)
>>>
>>
>> That's not possible, because we don't want to add external dependencies
>> to commons-lang.
>>
>
> I mistakenly thought that your examples (cf. uncut previous post) meant
> that this CM-alike tradition was coming to an end...
>
> Anyway, assuming there are still good reasons for CL to not have
> dependencies[1], it is then all the more interesting that utilities
> based on RNGs should have their own component.
>
> CL would benefit (reduced codebase reduces the maintenance cost)
> and users would benefit (from using better generators).
>
> Moreover, the default RNG should be a good one, i.e. not
>>> "java.util.Random".
>>>
>>
>> Using java.util.Random by default is good enough, and it's consistent
>> with Collections.shuffle():
>>
>>
>> http://docs.oracle.com/javase/8/docs/api/java/util/Collectio
>> ns.html#shuffle-java.util.List-
>>
>
> Well, of course, the JDK utilities use the JDK's RNG.
>
> That doesn't mean that Apache should do the same, or spread bad
> practice:
> http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
> (see page 2 about "java.util.Random").
>
> Gilles
>
> [1] Even if those would be in our total control!
>
>
>
>> Emmanuel Bourg
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [lang] Shuffling arrays
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 27 Sep 2016 13:57:04 +0200, Emmanuel Bourg wrote:
> Le 27/09/2016 � 13:22, Gilles a �crit :
>
>> I (strongly) suggest
>>
>> ArraysUtils.shuffle(Object[] array,
>> o.a.c.rng.UniformRandomProvider rnd)
>
> That's not possible, because we don't want to add external
> dependencies
> to commons-lang.
I mistakenly thought that your examples (cf. uncut previous post) meant
that this CM-alike tradition was coming to an end...
Anyway, assuming there are still good reasons for CL to not have
dependencies[1], it is then all the more interesting that utilities
based on RNGs should have their own component.
CL would benefit (reduced codebase reduces the maintenance cost)
and users would benefit (from using better generators).
>> Moreover, the default RNG should be a good one, i.e. not
>> "java.util.Random".
>
> Using java.util.Random by default is good enough, and it's consistent
> with Collections.shuffle():
>
>
> http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#shuffle-java.util.List-
Well, of course, the JDK utilities use the JDK's RNG.
That doesn't mean that Apache should do the same, or spread bad
practice:
http://www0.cs.ucl.ac.uk/staff/d.jones/GoodPracticeRNG.pdf
(see page 2 about "java.util.Random").
Gilles
[1] Even if those would be in our total control!
>
> Emmanuel Bourg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 27/09/2016 � 13:22, Gilles a �crit :
> I (strongly) suggest
>
> ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider rnd)
That's not possible, because we don't want to add external dependencies
to commons-lang.
> Moreover, the default RNG should be a good one, i.e. not
> "java.util.Random".
Using java.util.Random by default is good enough, and it's consistent
with Collections.shuffle():
http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#shuffle-java.util.List-
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Get things moving with "random utilities"
Posted by Dave Brosius <db...@apache.org>.
+1
---
<br type="_moz" />
On 2016-10-19 13:43, J�rg Schaible wrote:
> Hi,
>
> Gary Gregory wrote:
>
>> To restate my opinion and that of others: It is not a good thing to
>> end up
>> with components Commons Random A, Commons Random B, Commons Random C,
>> and
>> so on. We already have a new Commons Random Something component.
>> Related
>> code should be modules of that component.
>
> let's see it from the practical side. Commons RNG is supposed to stay
> stable
> as long as possible. Commons RNG Tools might have a much faster turn to
> break APIs. If you put both together, you'll have either to manage the
> submodules like individual components with own GAV (and where's the
> benefit
> then apart from our unprepared tooling of such an scenario?) or you
> have to
> change the package name of Commons RNG quite more often then necessary,
> just
> because you restructure something in the RNG tools that is
> incaompatible
> (not very good for users of RNG).
>
> Therefore I'm with Gilles here and would simply say: Let's try it with
> two
> independent components and time will tell if it was a good choice or
> not.
>
> Cheers,
> J�rg
>
>
> ---------------------------------------------------------------------
> 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: [ALL] Get things moving with "random utilities"
Posted by Jörg Schaible <jo...@gmx.de>.
Hi,
Gary Gregory wrote:
> To restate my opinion and that of others: It is not a good thing to end up
> with components Commons Random A, Commons Random B, Commons Random C, and
> so on. We already have a new Commons Random Something component. Related
> code should be modules of that component.
let's see it from the practical side. Commons RNG is supposed to stay stable
as long as possible. Commons RNG Tools might have a much faster turn to
break APIs. If you put both together, you'll have either to manage the
submodules like individual components with own GAV (and where's the benefit
then apart from our unprepared tooling of such an scenario?) or you have to
change the package name of Commons RNG quite more often then necessary, just
because you restructure something in the RNG tools that is incaompatible
(not very good for users of RNG).
Therefore I'm with Gilles here and would simply say: Let's try it with two
independent components and time will tell if it was a good choice or not.
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Get things moving with "random utilities"
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
Got it. Happy to contribute to an existing component (or a component's module) too.
Not sure where would be the best place. Right now the code I'd like to fix is in [lang],
used to generate random strings.
It is using Java default util Random object, and would be nice to let users change the seed,
but also use different random number generators.
Maybe the code could be a component of [rng], or maybe it could keep in [lang] and then just
provide a way for users to supply a random number generator... though I'm not really
sure if there is a common interface for these number generators. That way an alternative would be
simply generify the RandomStringUtils.
Cheers
B
>________________________________
> From: Gary Gregory <ga...@gmail.com>
>To: Commons Developers List <de...@commons.apache.org>
>Sent: Wednesday, 19 October 2016 4:46 AM
>Subject: Re: [ALL] Get things moving with "random utilities"
>
>
>To restate my opinion and that of others: It is not a good thing to end up
>with components Commons Random A, Commons Random B, Commons Random C, and
>so on. We already have a new Commons Random Something component. Related
>code should be modules of that component.
>
>Gary
>
>
>On Tue, Oct 18, 2016 at 7:18 AM, Gilles <gi...@harfang.homelinux.org>
>wrote:
>
>> Hello Bruno.
>>
>> On Sat, 15 Oct 2016 20:57:04 +0000 (UTC), Bruno P. Kinoshita wrote:
>>
>>> Hi Gilles,
>>>
>>> Definitely interested in helping and learning more about random
>>> (number|string|object|etc) generators.
>>>
>>> Are there any specific tasks that others can jump in and help with?
>>>
>>
>> In the yet-to-be-named "Commons <random utilities>" component,
>> everything is up for grabs, from extracting the relevant bits
>> from "Math" and "Lang", to proposing an all-encompassing
>> framework (if people think they can achieve it...).
>> The scope is open-ended (or should be defined if there is a
>> willingness to impose some limit).
>>
>> Once the new component has been set up,
>>>
>>
>> For this, we should start with settling on a name, so that INFRA
>> can create a repository with that name.
>>
>> * Random Utilities
>> * Random Utils
>> * Random Tools
>> * ...
>>
>> ?
>>
>> I'd be happy in trying to work
>>> on code related to LANG-1196 and LANG-1254.
>>>
>>
>> Thanks!
>>
>> Regards,
>> Gilles
>>
>>
>>
>>> Cheers
>>> Bruno
>>>
>>>> ________________________________
>>>> From: Gilles <gi...@harfang.homelinux.org>
>>>> To: dev@commons.apache.org
>>>> Sent: Sunday, 16 October 2016 5:08 AM
>>>> Subject: [ALL] Get things moving with "random utilities" (Was: [lang]
>>>> Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>>>>
>>>>
>>>> Hi.
>>>>
>>>> On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>> But overall it would be much better to put all this in a new
>>>>>> component
>>>>>> and deprecate all of CL's "Random"-parameterized methods.
>>>>>> It was noted (not only by me) that CL grew too big (and out of its
>>>>>> original
>>>>>> scope). "RandomUtils" is relatively small (in Lang 3.4): now is a
>>>>>> good
>>>>>> opportunity to deprecate these few methods and those intended for
>>>>>> 3.5
>>>>>> and redirect users to a dedicated component.
>>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>> [...]
>>>>>>
>>>>>
>>>> Within the context of a forthcoming release of "Commons RNG" and
>>>> identified shortcomings of the random-related utilities implemented
>>>> in "Commons Lang", e.g.:
>>>> https://issues.apache.org/jira/browse/LANG-1196
>>>> https://issues.apache.org/jira/browse/LANG-1254
>>>> I'm proposing to ask INFRA to create a new git repository, to become
>>>> the "Commons" home of random utilities, i.e. anything that _uses_ an
>>>> "external" source of randomness (as opposed to _implementations_
>>>> of (P)RNG algorithms, which is the scope of "Commons RNG").
>>>>
>>>> Examples of utilities:
>>>> * non-uniform deviates (to be extracted from "Commons Math")
>>>> * extended tools, such as "numbers within a range" (to be
>>>> extracted from "Commons Lang") and "quasi-random" generators
>>>> (to be extracted from "Commons Math"),
>>>> * string utilities (to be extracted from "Commons Math" and
>>>> "Commons Lang"),
>>>> * shuffling of primitive arrays and "List<T>" (to be extracted
>>>> from "Commons Math"),
>>>> * bridges between alternative APIs:
>>>> - java.util.Random
>>>> - java.util.SplittableRandom
>>>> - UniformRandomProvider from "Commons RNG" (to be extracted
>>>> from "Commons Math")
>>>> - other Java libraries
>>>> * wrappers around "external" sources of randomness, e.g. system
>>>> devices (UNIX) and native libraries, and interface extensions
>>>> needed to support them (streams, IO handling, etc.).
>>>>
>>>> Given the variety of the above (non-exhaustive) list, it is
>>>> foreseen that the component will be "multi-modules"[1] in order
>>>> to let users depend only on what they need for their use-case.
>>>> [For example, an engineering application could need non-uniform
>>>> deviates (e.g. Gaussian-distributed sequences), but should not
>>>> be required to depend on the (orthogonal) development of string
>>>> generators or cryptographic features.]
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>> [1] Help is most welcome to set this up.
>>>>
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>--
>E-Mail: garydgregory@gmail.com | ggregory@apache.org
>Java Persistence with Hibernate, Second Edition
><https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
><http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>JUnit in Action, Second Edition
><https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>
><http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>Spring Batch in Action
><https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
><http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>Blog: http://garygregory.wordpress.com
>Home: http://garygregory.com/
>Tweet! http://twitter.com/GaryGregory
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Get things moving with "random utilities"
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 18 Oct 2016 08:46:25 -0700, Gary Gregory wrote:
> To restate my opinion and that of others: It is not a good thing to
> end up
> with components Commons Random A, Commons Random B, Commons Random C,
> and
> so on. We already have a new Commons Random Something component.
> Related
> code should be modules of that component.
I'll restate my opinion that it is a bad idea to do it.
But, furthermore, I'll give the reason why it is a bad
idea: We should not confuse the use of a functionality,
with the functionality itself.
What you say above ("related code should be modules") is
akin to saying that all codes that use <some Java interface>
must be shipped in a single library.
[Going even further and citing Jochen, again, the utilities
should be "random source"-neutral (i.e. have their own "RNG"
interface upon which the tools are built), and possibly
provide bridges to/from other libraries API (including a.o.
"UniformRandomProvider" (from "Commons RNG") and the JDK's
"java.util.Random" and "java.util.SplittableRandom".]
Don't you rather think that a good "component" is one that
focuses on its job, without being encumbered by out-of-scope
considerations?
The envisioned "tools" will be on very unstable ground
(their scope is yet _undefined_) for a long time[1], while
"Commons RNG" is (within a scope intended to fit a bona fide
"component") features-complete. [Well, other features would
be welcome (as I already noted elsewhere), but they are
certainly not required for a "simple API" (which, I suppose,
covers the vast majority of use-cases).]
The two candidate components are completely different beasts.
Grouping them for the sole reason that they both use the word
"random" in their description is a dramatic oversimplification.
[I'm surprised that you do not request that "Commons Crypto"[2]
be merged into "Commons RNG" (or should it be the reverse?)...]
There are many reasons why we all should prefer to keep them
separate.[3]
Perhaps, in the long-term[4], when all the dust has settled,
will I see reasons to merge the two libraries.
In the meantime, none exist (there is no code, is there?),
and I fail to understand how
* jeopardizing the stability of an existing codebase, and
* delaying its releases (on the ground that non-existing
code might be added at some indeterminate future)
are "good thing[s]".
My proposal is _two_[5] components, not "A, B, C and so on"!
One will, some day, provide many modules as client code of any
supported "random sources",[6] and the other can provide, right
now, PRNGs implementations (as a particular type of "random
source").[7]
Sadly, if your above statement uses exaggeration in order to
deform this proposal, it does not give any "positive" argument
against it, for us to think about.
Please, give technical objections to my (positive) arguments.
Regards,
Gilles
[1] The absence of SMEs will increase the number of ways of
getting some of those tools wrong (entailing the need to
break compatibility in order to correct the course).
This happened in CM.
[2]
http://commons.apache.org/proper/commons-crypto/apidocs/org/apache/commons/crypto/random/CryptoRandom.html
[3] Stated soooo many times in several other threads.
[4] When people have actually _experimented_ with the ideas
which they think "should work".
[5] It is true however that other "random sources", with features
that _provably_ go beyond the scope of "Commons RNG", should
(IMO) be developed in an additional component, if "separation
of concerns" is something of value to this community.
[6] As explicitly described in the original post (quoted below).
[7] If the name of "Commons RNG" is still the source, not of
uniform randomness, but of community confusion, I'm all for
changing it, so that it more precisely reflect the intended
contents.
>
> Gary
>
> On Tue, Oct 18, 2016 at 7:18 AM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> Hello Bruno.
>>
>> On Sat, 15 Oct 2016 20:57:04 +0000 (UTC), Bruno P. Kinoshita wrote:
>>
>>> Hi Gilles,
>>>
>>> Definitely interested in helping and learning more about random
>>> (number|string|object|etc) generators.
>>>
>>> Are there any specific tasks that others can jump in and help with?
>>>
>>
>> In the yet-to-be-named "Commons <random utilities>" component,
>> everything is up for grabs, from extracting the relevant bits
>> from "Math" and "Lang", to proposing an all-encompassing
>> framework (if people think they can achieve it...).
>> The scope is open-ended (or should be defined if there is a
>> willingness to impose some limit).
>>
>> Once the new component has been set up,
>>>
>>
>> For this, we should start with settling on a name, so that INFRA
>> can create a repository with that name.
>>
>> * Random Utilities
>> * Random Utils
>> * Random Tools
>> * ...
>>
>> ?
>>
>> I'd be happy in trying to work
>>> on code related to LANG-1196 and LANG-1254.
>>>
>>
>> Thanks!
>>
>> Regards,
>> Gilles
>>
>>
>>
>>> Cheers
>>> Bruno
>>>
>>>> ________________________________
>>>> From: Gilles <gi...@harfang.homelinux.org>
>>>> To: dev@commons.apache.org
>>>> Sent: Sunday, 16 October 2016 5:08 AM
>>>> Subject: [ALL] Get things moving with "random utilities" (Was:
>>>> [lang]
>>>> Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>>>>
>>>>
>>>> Hi.
>>>>
>>>> On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>> But overall it would be much better to put all this in a new
>>>>>> component
>>>>>> and deprecate all of CL's "Random"-parameterized methods.
>>>>>> It was noted (not only by me) that CL grew too big (and out of
>>>>>> its
>>>>>> original
>>>>>> scope). "RandomUtils" is relatively small (in Lang 3.4): now is
>>>>>> a
>>>>>> good
>>>>>> opportunity to deprecate these few methods and those intended
>>>>>> for
>>>>>> 3.5
>>>>>> and redirect users to a dedicated component.
>>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>> [...]
>>>>>>
>>>>>
>>>> Within the context of a forthcoming release of "Commons RNG" and
>>>> identified shortcomings of the random-related utilities
>>>> implemented
>>>> in "Commons Lang", e.g.:
>>>> https://issues.apache.org/jira/browse/LANG-1196
>>>> https://issues.apache.org/jira/browse/LANG-1254
>>>> I'm proposing to ask INFRA to create a new git repository, to
>>>> become
>>>> the "Commons" home of random utilities, i.e. anything that _uses_
>>>> an
>>>> "external" source of randomness (as opposed to _implementations_
>>>> of (P)RNG algorithms, which is the scope of "Commons RNG").
>>>>
>>>> Examples of utilities:
>>>> * non-uniform deviates (to be extracted from "Commons Math")
>>>> * extended tools, such as "numbers within a range" (to be
>>>> extracted from "Commons Lang") and "quasi-random" generators
>>>> (to be extracted from "Commons Math"),
>>>> * string utilities (to be extracted from "Commons Math" and
>>>> "Commons Lang"),
>>>> * shuffling of primitive arrays and "List<T>" (to be extracted
>>>> from "Commons Math"),
>>>> * bridges between alternative APIs:
>>>> - java.util.Random
>>>> - java.util.SplittableRandom
>>>> - UniformRandomProvider from "Commons RNG" (to be extracted
>>>> from "Commons Math")
>>>> - other Java libraries
>>>> * wrappers around "external" sources of randomness, e.g. system
>>>> devices (UNIX) and native libraries, and interface extensions
>>>> needed to support them (streams, IO handling, etc.).
>>>>
>>>> Given the variety of the above (non-exhaustive) list, it is
>>>> foreseen that the component will be "multi-modules"[1] in order
>>>> to let users depend only on what they need for their use-case.
>>>> [For example, an engineering application could need non-uniform
>>>> deviates (e.g. Gaussian-distributed sequences), but should not
>>>> be required to depend on the (orthogonal) development of string
>>>> generators or cryptographic features.]
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>> [1] Help is most welcome to set this up.
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Get things moving with "random utilities"
Posted by Gary Gregory <ga...@gmail.com>.
To restate my opinion and that of others: It is not a good thing to end up
with components Commons Random A, Commons Random B, Commons Random C, and
so on. We already have a new Commons Random Something component. Related
code should be modules of that component.
Gary
On Tue, Oct 18, 2016 at 7:18 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> Hello Bruno.
>
> On Sat, 15 Oct 2016 20:57:04 +0000 (UTC), Bruno P. Kinoshita wrote:
>
>> Hi Gilles,
>>
>> Definitely interested in helping and learning more about random
>> (number|string|object|etc) generators.
>>
>> Are there any specific tasks that others can jump in and help with?
>>
>
> In the yet-to-be-named "Commons <random utilities>" component,
> everything is up for grabs, from extracting the relevant bits
> from "Math" and "Lang", to proposing an all-encompassing
> framework (if people think they can achieve it...).
> The scope is open-ended (or should be defined if there is a
> willingness to impose some limit).
>
> Once the new component has been set up,
>>
>
> For this, we should start with settling on a name, so that INFRA
> can create a repository with that name.
>
> * Random Utilities
> * Random Utils
> * Random Tools
> * ...
>
> ?
>
> I'd be happy in trying to work
>> on code related to LANG-1196 and LANG-1254.
>>
>
> Thanks!
>
> Regards,
> Gilles
>
>
>
>> Cheers
>> Bruno
>>
>>> ________________________________
>>> From: Gilles <gi...@harfang.homelinux.org>
>>> To: dev@commons.apache.org
>>> Sent: Sunday, 16 October 2016 5:08 AM
>>> Subject: [ALL] Get things moving with "random utilities" (Was: [lang]
>>> Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>>>
>>>
>>> Hi.
>>>
>>> On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>>>
>>>> [...]
>>>>
>>>>>
>>>>> But overall it would be much better to put all this in a new
>>>>> component
>>>>> and deprecate all of CL's "Random"-parameterized methods.
>>>>> It was noted (not only by me) that CL grew too big (and out of its
>>>>> original
>>>>> scope). "RandomUtils" is relatively small (in Lang 3.4): now is a
>>>>> good
>>>>> opportunity to deprecate these few methods and those intended for
>>>>> 3.5
>>>>> and redirect users to a dedicated component.
>>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>>> [...]
>>>>>
>>>>
>>> Within the context of a forthcoming release of "Commons RNG" and
>>> identified shortcomings of the random-related utilities implemented
>>> in "Commons Lang", e.g.:
>>> https://issues.apache.org/jira/browse/LANG-1196
>>> https://issues.apache.org/jira/browse/LANG-1254
>>> I'm proposing to ask INFRA to create a new git repository, to become
>>> the "Commons" home of random utilities, i.e. anything that _uses_ an
>>> "external" source of randomness (as opposed to _implementations_
>>> of (P)RNG algorithms, which is the scope of "Commons RNG").
>>>
>>> Examples of utilities:
>>> * non-uniform deviates (to be extracted from "Commons Math")
>>> * extended tools, such as "numbers within a range" (to be
>>> extracted from "Commons Lang") and "quasi-random" generators
>>> (to be extracted from "Commons Math"),
>>> * string utilities (to be extracted from "Commons Math" and
>>> "Commons Lang"),
>>> * shuffling of primitive arrays and "List<T>" (to be extracted
>>> from "Commons Math"),
>>> * bridges between alternative APIs:
>>> - java.util.Random
>>> - java.util.SplittableRandom
>>> - UniformRandomProvider from "Commons RNG" (to be extracted
>>> from "Commons Math")
>>> - other Java libraries
>>> * wrappers around "external" sources of randomness, e.g. system
>>> devices (UNIX) and native libraries, and interface extensions
>>> needed to support them (streams, IO handling, etc.).
>>>
>>> Given the variety of the above (non-exhaustive) list, it is
>>> foreseen that the component will be "multi-modules"[1] in order
>>> to let users depend only on what they need for their use-case.
>>> [For example, an engineering application could need non-uniform
>>> deviates (e.g. Gaussian-distributed sequences), but should not
>>> be required to depend on the (orthogonal) development of string
>>> generators or cryptographic features.]
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> [1] Help is most welcome to set this up.
>>>
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [ALL] Get things moving with "random utilities"
Posted by Gilles <gi...@harfang.homelinux.org>.
Hello Bruno.
On Sat, 15 Oct 2016 20:57:04 +0000 (UTC), Bruno P. Kinoshita wrote:
> Hi Gilles,
>
> Definitely interested in helping and learning more about random
> (number|string|object|etc) generators.
>
> Are there any specific tasks that others can jump in and help with?
In the yet-to-be-named "Commons <random utilities>" component,
everything is up for grabs, from extracting the relevant bits
from "Math" and "Lang", to proposing an all-encompassing
framework (if people think they can achieve it...).
The scope is open-ended (or should be defined if there is a
willingness to impose some limit).
> Once the new component has been set up,
For this, we should start with settling on a name, so that INFRA
can create a repository with that name.
* Random Utilities
* Random Utils
* Random Tools
* ...
?
> I'd be happy in trying to work
> on code related to LANG-1196 and LANG-1254.
Thanks!
Regards,
Gilles
>
> Cheers
> Bruno
>>________________________________
>> From: Gilles <gi...@harfang.homelinux.org>
>>To: dev@commons.apache.org
>>Sent: Sunday, 16 October 2016 5:08 AM
>>Subject: [ALL] Get things moving with "random utilities" (Was: [lang]
>> Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>>
>>
>>Hi.
>>
>>On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>>> [...]
>>>>
>>>> But overall it would be much better to put all this in a new
>>>> component
>>>> and deprecate all of CL's "Random"-parameterized methods.
>>>> It was noted (not only by me) that CL grew too big (and out of its
>>>> original
>>>> scope). "RandomUtils" is relatively small (in Lang 3.4): now is a
>>>> good
>>>> opportunity to deprecate these few methods and those intended for
>>>> 3.5
>>>> and redirect users to a dedicated component.
>>>
>>> +1
>>>
>>>>
>>>> [...]
>>
>>Within the context of a forthcoming release of "Commons RNG" and
>>identified shortcomings of the random-related utilities implemented
>>in "Commons Lang", e.g.:
>> https://issues.apache.org/jira/browse/LANG-1196
>> https://issues.apache.org/jira/browse/LANG-1254
>>I'm proposing to ask INFRA to create a new git repository, to become
>>the "Commons" home of random utilities, i.e. anything that _uses_ an
>>"external" source of randomness (as opposed to _implementations_
>>of (P)RNG algorithms, which is the scope of "Commons RNG").
>>
>>Examples of utilities:
>> * non-uniform deviates (to be extracted from "Commons Math")
>> * extended tools, such as "numbers within a range" (to be
>> extracted from "Commons Lang") and "quasi-random" generators
>> (to be extracted from "Commons Math"),
>> * string utilities (to be extracted from "Commons Math" and
>> "Commons Lang"),
>> * shuffling of primitive arrays and "List<T>" (to be extracted
>> from "Commons Math"),
>> * bridges between alternative APIs:
>> - java.util.Random
>> - java.util.SplittableRandom
>> - UniformRandomProvider from "Commons RNG" (to be extracted
>> from "Commons Math")
>> - other Java libraries
>> * wrappers around "external" sources of randomness, e.g. system
>> devices (UNIX) and native libraries, and interface extensions
>> needed to support them (streams, IO handling, etc.).
>>
>>Given the variety of the above (non-exhaustive) list, it is
>>foreseen that the component will be "multi-modules"[1] in order
>>to let users depend only on what they need for their use-case.
>>[For example, an engineering application could need non-uniform
>>deviates (e.g. Gaussian-distributed sequences), but should not
>>be required to depend on the (orthogonal) development of string
>>generators or cryptographic features.]
>>
>>
>>Regards,
>>Gilles
>>
>>[1] Help is most welcome to set this up.
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [ALL] Get things moving with "random utilities" (Was: [lang]
Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
Posted by "Bruno P. Kinoshita" <br...@yahoo.com.br.INVALID>.
Hi Gilles,
Definitely interested in helping and learning more about random (number|string|object|etc) generators.
Are there any specific tasks that others can jump in and help with? Once the new component has been set up, I'd be happy in trying to work on code related to LANG-1196 and LANG-1254.
Cheers
Bruno
>________________________________
> From: Gilles <gi...@harfang.homelinux.org>
>To: dev@commons.apache.org
>Sent: Sunday, 16 October 2016 5:08 AM
>Subject: [ALL] Get things moving with "random utilities" (Was: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
>
>
>Hi.
>
>On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
>> [...]
>>>
>>> But overall it would be much better to put all this in a new
>>> component
>>> and deprecate all of CL's "Random"-parameterized methods.
>>> It was noted (not only by me) that CL grew too big (and out of its
>>> original
>>> scope). "RandomUtils" is relatively small (in Lang 3.4): now is a
>>> good
>>> opportunity to deprecate these few methods and those intended for
>>> 3.5
>>> and redirect users to a dedicated component.
>>
>> +1
>>
>>>
>>> [...]
>
>Within the context of a forthcoming release of "Commons RNG" and
>identified shortcomings of the random-related utilities implemented
>in "Commons Lang", e.g.:
> https://issues.apache.org/jira/browse/LANG-1196
> https://issues.apache.org/jira/browse/LANG-1254
>I'm proposing to ask INFRA to create a new git repository, to become
>the "Commons" home of random utilities, i.e. anything that _uses_ an
>"external" source of randomness (as opposed to _implementations_
>of (P)RNG algorithms, which is the scope of "Commons RNG").
>
>Examples of utilities:
> * non-uniform deviates (to be extracted from "Commons Math")
> * extended tools, such as "numbers within a range" (to be
> extracted from "Commons Lang") and "quasi-random" generators
> (to be extracted from "Commons Math"),
> * string utilities (to be extracted from "Commons Math" and
> "Commons Lang"),
> * shuffling of primitive arrays and "List<T>" (to be extracted
> from "Commons Math"),
> * bridges between alternative APIs:
> - java.util.Random
> - java.util.SplittableRandom
> - UniformRandomProvider from "Commons RNG" (to be extracted
> from "Commons Math")
> - other Java libraries
> * wrappers around "external" sources of randomness, e.g. system
> devices (UNIX) and native libraries, and interface extensions
> needed to support them (streams, IO handling, etc.).
>
>Given the variety of the above (non-exhaustive) list, it is
>foreseen that the component will be "multi-modules"[1] in order
>to let users depend only on what they need for their use-case.
>[For example, an engineering application could need non-uniform
>deviates (e.g. Gaussian-distributed sequences), but should not
>be required to depend on the (orthogonal) development of string
>generators or cryptographic features.]
>
>
>Regards,
>Gilles
>
>[1] Help is most welcome to set this up.
>
>
>
>---------------------------------------------------------------------
>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
[ALL] Get things moving with "random utilities" (Was: [lang]
Shuffling arrays (was: [RNG] Scope of "Commons RNG"))
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Fri, 7 Oct 2016 16:00:05 +0100, sebb wrote:
> [...]
>>
>> But overall it would be much better to put all this in a new
>> component
>> and deprecate all of CL's "Random"-parameterized methods.
>> It was noted (not only by me) that CL grew too big (and out of its
>> original
>> scope). "RandomUtils" is relatively small (in Lang 3.4): now is a
>> good
>> opportunity to deprecate these few methods and those intended for
>> 3.5
>> and redirect users to a dedicated component.
>
> +1
>
>>
>> [...]
Within the context of a forthcoming release of "Commons RNG" and
identified shortcomings of the random-related utilities implemented
in "Commons Lang", e.g.:
https://issues.apache.org/jira/browse/LANG-1196
https://issues.apache.org/jira/browse/LANG-1254
I'm proposing to ask INFRA to create a new git repository, to become
the "Commons" home of random utilities, i.e. anything that _uses_ an
"external" source of randomness (as opposed to _implementations_
of (P)RNG algorithms, which is the scope of "Commons RNG").
Examples of utilities:
* non-uniform deviates (to be extracted from "Commons Math")
* extended tools, such as "numbers within a range" (to be
extracted from "Commons Lang") and "quasi-random" generators
(to be extracted from "Commons Math"),
* string utilities (to be extracted from "Commons Math" and
"Commons Lang"),
* shuffling of primitive arrays and "List<T>" (to be extracted
from "Commons Math"),
* bridges between alternative APIs:
- java.util.Random
- java.util.SplittableRandom
- UniformRandomProvider from "Commons RNG" (to be extracted
from "Commons Math")
- other Java libraries
* wrappers around "external" sources of randomness, e.g. system
devices (UNIX) and native libraries, and interface extensions
needed to support them (streams, IO handling, etc.).
Given the variety of the above (non-exhaustive) list, it is
foreseen that the component will be "multi-modules"[1] in order
to let users depend only on what they need for their use-case.
[For example, an engineering application could need non-uniform
deviates (e.g. Gaussian-distributed sequences), but should not
be required to depend on the (orthogonal) development of string
generators or cryptographic features.]
Regards,
Gilles
[1] Help is most welcome to set this up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG")
Posted by sebb <se...@gmail.com>.
On 27 September 2016 at 12:22, Gilles <gi...@harfang.homelinux.org> wrote:
> Hi.
>
> On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
>>
>> Le 27/09/2016 à 01:14, Gilles a écrit :
>>
>>>>> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
>>>>
>>>>
>>>> This should go in the ArrayUtils class of commons-lang, with a
>>>> java.util.Random parameter.
>>>
>>>
>>> I don't get that.
>>> The idea is to parameterize the utilities with a "UniformRandomProvider"
>>> instance.
>>
>>
>> My suggestion is to add two methods to ArrayUtils in commons-lang for
>> each primitive type and Object (and maybe a couple more if we want to
>> shuffle only a subset of the array):
>>
>> ArraysUtils.shuffle(Object[] array)
>> ArraysUtils.shuffle(Object[] array, java.util.Random rnd)
>
>
> I (strongly) suggest
>
> ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider rnd)
Huh?
That would require LANG to depend on RNG.
I am against that.
>>
>> And if we want to shuffle with a random generator from commons-rng, we
>> simply convert the UniformRandomProvider into a java.util.Random using
>> the adapter:
>>
>> RandomProvider rng = RandomSource.create(...);
>> ArraysUtils.shuffle(array, new JDKRandomAdapter(rng));
>>
>> or
>>
>> RandomProvider rng = RandomSource.create(...);
>> ArraysUtils.shuffle(array, rng.asRandom());
>
>
> Similarly, we'd rather overload "shuffle" as follows
>
> ArraysUtils.shuffle(Object[] array, java.util.Random rnd) {
> shuffle(array, RandomUtils.asUniformRandomProvider(rnd));
> }
>
> where "RandomUtils" is currently in CM (package "o.a.c.math4.random").
>
> It is not a matter of taste (cf. caveat in "o.a.c.math4.random.RngAdpator").
> The factory method "asUniformRandomProvider" creates an instance that
> redirects all the interface methods to their counterpart in "Random" (when
> they exist): sequence of any type is the same, whether the Random instance
> is wrapped or not. "RngAdapter" however creates a "Random" instance where
> only 32-bits integers sequences are preserved.
>
> Moreover, the default RNG should be a good one, i.e. not "java.util.Random".
>
> But overall it would be much better to put all this in a new component
> and deprecate all of CL's "Random"-parameterized methods.
> It was noted (not only by me) that CL grew too big (and out of its original
> scope). "RandomUtils" is relatively small (in Lang 3.4): now is a good
> opportunity to deprecate these few methods and those intended for 3.5
> and redirect users to a dedicated component.
+1
>
> Gilles
>
>
>> Emmanuel Bourg
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG")
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Tue, 27 Sep 2016 12:53:33 +0200, Emmanuel Bourg wrote:
> Le 27/09/2016 � 01:14, Gilles a �crit :
>
>>>> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
>>>
>>> This should go in the ArrayUtils class of commons-lang, with a
>>> java.util.Random parameter.
>>
>> I don't get that.
>> The idea is to parameterize the utilities with a
>> "UniformRandomProvider"
>> instance.
>
> My suggestion is to add two methods to ArrayUtils in commons-lang for
> each primitive type and Object (and maybe a couple more if we want to
> shuffle only a subset of the array):
>
> ArraysUtils.shuffle(Object[] array)
> ArraysUtils.shuffle(Object[] array, java.util.Random rnd)
I (strongly) suggest
ArraysUtils.shuffle(Object[] array, o.a.c.rng.UniformRandomProvider
rnd)
>
> And if we want to shuffle with a random generator from commons-rng,
> we
> simply convert the UniformRandomProvider into a java.util.Random
> using
> the adapter:
>
> RandomProvider rng = RandomSource.create(...);
> ArraysUtils.shuffle(array, new JDKRandomAdapter(rng));
>
> or
>
> RandomProvider rng = RandomSource.create(...);
> ArraysUtils.shuffle(array, rng.asRandom());
Similarly, we'd rather overload "shuffle" as follows
ArraysUtils.shuffle(Object[] array, java.util.Random rnd) {
shuffle(array, RandomUtils.asUniformRandomProvider(rnd));
}
where "RandomUtils" is currently in CM (package "o.a.c.math4.random").
It is not a matter of taste (cf. caveat in
"o.a.c.math4.random.RngAdpator").
The factory method "asUniformRandomProvider" creates an instance that
redirects all the interface methods to their counterpart in "Random"
(when
they exist): sequence of any type is the same, whether the Random
instance
is wrapped or not. "RngAdapter" however creates a "Random" instance
where
only 32-bits integers sequences are preserved.
Moreover, the default RNG should be a good one, i.e. not
"java.util.Random".
But overall it would be much better to put all this in a new component
and deprecate all of CL's "Random"-parameterized methods.
It was noted (not only by me) that CL grew too big (and out of its
original
scope). "RandomUtils" is relatively small (in Lang 3.4): now is a good
opportunity to deprecate these few methods and those intended for 3.5
and redirect users to a dedicated component.
Gilles
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org