You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles <gi...@harfang.homelinux.org> on 2016/09/21 12:46:12 UTC
[RNG] Scope of "Commons RNG"
Hello.
This is a post to ask about what we want "Commons RNG"
to be (as a service to the users).
In the Wikipedia pages referred to in the following
reports
https://issues.apache.org/jira/browse/RNG-16
https://issues.apache.org/jira/browse/RNG-17
the take-away message (IIUC) is that LCG and LFG are
almost never to be used.[1]
If we want "Commons RNG" to be a repository of all
generators that exist out there, irrespective of their
known weaknesses, it's fine; but we should be careful to
not let casual users just pick one of the implementations
on the premise that the library focuses on high quality
generators.
On the other hand, we could be wary of adding code[2]
that we'd then recommend to not use...
If, from some POV, it is deemed useful to have those,
the scope and overview of the component should mention,
prominently, the "caveat".[3]
I have no issue with adding any new implementation,[4]
on the conditions that it comes with
1. a unit test where the output (say, a few hundred
numbers) of "Commons RNG" is compared against a
"reference" implementation,[5]
2. the outputs of the "RandomStressTester"[6] piping
from the "Dieharder" and "TU01/BigCrush" actual
stress test suites.[7]
We should add a note to that effect somewhere in the
documentation, perhaps in "CONTRIBUTING.md" (?).
Regards,
Gilles
[1] Emmanuel, if you don't mind, we'd thus set the JIRA
issue "type" to "wish" rather than "improvement".
[2] https://xkcd.com/221/
[3] Up to now, I had assumed that no known-to-be-bad
generators would be part of "Commons RNG" (except
"JDK", for reference purposes).
[4] It is not a problem to wait another couple of weeks
for the additional code, before releasing 1.0.
[5] I.e. _not_ a "pre-run" of the same implementation!
[6] Source is in "src/userguide/java".
[7] Those software have to be installed separately.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] New implementations before release of 1.0
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 22 Sep 2016 17:50:23 +0200, J�rg Schaible wrote:
> Hi Gilles,
>
> Gilles wrote:
>
>> On Thu, 22 Sep 2016 14:29:37 +0200, J�rg Schaible wrote:
>>> Gilles wrote:
>>>
>>>> Hi.
>>>>
>>>> Release of version 1.0 will be delayed for another two weeks,
>>>> waiting for additional implementations.
>>>
>>> Then, please, cancel the still running vote also ;-)
>>
>> I'll do (the deadline was over anyways).
>
> The deadline just means that you wait to close the vote "at least"
> until.
I noticed that there are different formulation, with different
meanings.
But for that vote, the text said:
---CUT---
This vote will close in 72 hours, [...]
---CUT---
Regards,
Gilles
>
> 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: [RNG] New implementations before release of 1.0
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Jörg Schaible [mailto:joerg.schaible@bpm-inspire.com]
> Sent: Thursday, September 22, 2016 08:50
> To: dev@commons.apache.org
> Subject: Re: [RNG] New implementations before release of 1.0
>
> Hi Gilles,
>
> Gilles wrote:
>
> > On Thu, 22 Sep 2016 14:29:37 +0200, Jörg Schaible wrote:
> >> Gilles wrote:
> >>
> >>> Hi.
> >>>
> >>> Release of version 1.0 will be delayed for another two weeks,
> >>> waiting for additional implementations.
> >>
> >> Then, please, cancel the still running vote also ;-)
> >
> > I'll do (the deadline was over anyways).
>
> The deadline just means that you wait to close the vote "at least"
> until.
[orcmid]
I think it is the vote will be *open* "at least until." It is common to leave a [VOTE] open either because of discussion or to see if an additional ballot is forthcoming. I've started using "ending no earlier than <some-UTC-datetime>" in [VOTE]s I run.
I suppose the way [VOTE] threads end clearly is either with a [CANCEL] report or a [RESULT] report.
>
> 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: [RNG] New implementations before release of 1.0
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Hi Gilles,
Gilles wrote:
> On Thu, 22 Sep 2016 14:29:37 +0200, J�rg Schaible wrote:
>> Gilles wrote:
>>
>>> Hi.
>>>
>>> Release of version 1.0 will be delayed for another two weeks,
>>> waiting for additional implementations.
>>
>> Then, please, cancel the still running vote also ;-)
>
> I'll do (the deadline was over anyways).
The deadline just means that you wait to close the vote "at least" until.
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] New implementations before release of 1.0
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 22 Sep 2016 14:29:37 +0200, J�rg Schaible wrote:
> Gilles wrote:
>
>> Hi.
>>
>> Release of version 1.0 will be delayed for another two weeks,
>> waiting for additional implementations.
>
> Then, please, cancel the still running vote also ;-)
I'll do (the deadline was over anyways).
Gilles
>
> Cheers,
> J�rg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] New implementations before release of 1.0
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Gilles wrote:
> Hi.
>
> Release of version 1.0 will be delayed for another two weeks,
> waiting for additional implementations.
Then, please, cancel the still running vote also ;-)
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[RNG] New implementations before release of 1.0
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
Release of version 1.0 will be delayed for another two weeks,
waiting for additional implementations.
See:
https://issues.apache.org/jira/browse/RNG-16
https://issues.apache.org/jira/browse/RNG-17
If you intend to try and implement them, please assign the
issue to yourself.
Patches for other algorithms are welcome too.
Please note that any new implementation must come with
(1) a unit test where the output (say, a few hundred
numbers) of "Commons RNG" is compared against a
"reference" implementation,
(2) the outputs of the "RandomStressTester" piping
from the "Dieharder" and "TU01/BigCrush" actual
stress test suites.
If you provide the Java code and (1), I can take take care
of (2), since I have the software installed already.[1]
Regards,
Gilles
[1] Please take into account that it will take about 32
hours to run "BigCrush".
Hence, I'll start all the runs (3 "Dieharder" and 3
"BigCrush", per new implementation) in _one_ go.
---------------------------------------------------------------------
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
Re: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG")
Posted by Emmanuel Bourg <eb...@apache.org>.
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: [RNG] Scope of "Commons RNG"
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 26 Sep 2016 21:22:35 -0500, Brent Worden wrote:
>> First candidates are:
>>>> * Non-uniform deviates (i.e. the samplers now defined in
>>>> Commons Math's "o.a.c.math4.distribution" package),
>>>>
>>>
>>> I agree this doesn't belong to commons-rng, but I'm not convinced
>>> it
>>> would fit a commons-rng-tools component. Maybe a component more
>>> targeted
>>> toward statistic algorithms?
>>>
>>
>> Sampling and statistics do not necessarily belong together.
>> [This was a discussion in CM.]
>>
>>
> +1
>
> Having used commons-math to generate random deviates, the
> commons-math
> approach of coupling random deviate generation to the distributions
> themselves proved to be a bad development experience as well as not
> the
> most performant in the form of object instantiations.
Are you referring to the code in the 3.x line (branch "MATH_3_X"), or
in
the development branch (branch "master"[1]).
In unreleased CM4, the sampling is still coupled with the distribution
class but a RNG is passed only when a sampler is created.
> Specialized
> random variate generators would be a lot better design IMO.
If what's in CM4 is still not satisfactory, could you provide more
details on a better design?
Regards,
Gilles
[1] "Current" development branch was in branch "develop" until last
week.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] Scope of "Commons RNG"
Posted by Brent Worden <br...@gmail.com>.
> First candidates are:
>>> * Non-uniform deviates (i.e. the samplers now defined in
>>> Commons Math's "o.a.c.math4.distribution" package),
>>>
>>
>> I agree this doesn't belong to commons-rng, but I'm not convinced it
>> would fit a commons-rng-tools component. Maybe a component more targeted
>> toward statistic algorithms?
>>
>
> Sampling and statistics do not necessarily belong together.
> [This was a discussion in CM.]
>
>
+1
Having used commons-math to generate random deviates, the commons-math
approach of coupling random deviate generation to the distributions
themselves proved to be a bad development experience as well as not the
most performant in the form of object instantiations. Specialized
random variate generators would be a lot better design IMO.
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 30 Sep 2016 09:49:52 +0200, Emmanuel Bourg wrote:
> Le 29/09/2016 � 14:01, Gilles a �crit :
>
>>> \u200bI think other modules will be somehow dependent on rng-core, so
>>> change
>>> in core will require additional release of the module.\u200b
>>
>> Wrong!
>>
>> See previous post(s).
>
> Actually Artem is right. Changes in rng-core are likely to be used in
> rng-utils. For example the typed factory that you wanted to move to
> rng-utils would have to be updated every time a new random number
> generator is added to rng-core. New methods added to RandomSource or
> UniformRandomProvider could also be useful to rng-utils classes.
Here and in the other post, you are totally oblivious to my POV.
The potential target audience of the component which I proposed
does not need what I called "rng-utils".
[In particular, they don't need the factory you want to use place
of the one I've coded.]
The target audience is those applications that would need a RNG
implemented in Java. Period.
In that use-case, the complexity is what you create by forcing
the "rng-core" version (of a limited-scope library, which is a
good thing) to step in sync with the changes in "rng-utils" (a
non-limited library, which is not a bad thing per se, but
definitely _more_ complex to manage).
Gilles
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 29/09/2016 � 14:01, Gilles a �crit :
>> \u200bI think other modules will be somehow dependent on rng-core, so change
>> in core will require additional release of the module.\u200b
>
> Wrong!
>
> See previous post(s).
Actually Artem is right. Changes in rng-core are likely to be used in
rng-utils. For example the typed factory that you wanted to move to
rng-utils would have to be updated every time a new random number
generator is added to rng-core. New methods added to RandomSource or
UniformRandomProvider could also be useful to rng-utils classes.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 29 Sep 2016 14:41:11 +0300, Artem Barger wrote:
> On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes
> <st...@apache.org>
> wrote:
>
>> A good question is - if rng-core changes - would the other modules
>> need to change as well? If not, then there's not a big reason why
>> they
>> need to be together in the same project (but we would end up with
>> Commons Commons Components..)
>>
>
> \u200bI think other modules will be somehow dependent on rng-core, so
> change
> in core will require additional release of the module.\u200b
Wrong!
See previous post(s).
Gilles
>
> Best regards,
> Artem Barger.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Artem Barger <ar...@bargr.net>.
On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes <st...@apache.org>
wrote:
> A good question is - if rng-core changes - would the other modules
> need to change as well? If not, then there's not a big reason why they
> need to be together in the same project (but we would end up with
> Commons Commons Components..)
>
I think other modules will be somehow dependent on rng-core, so change
in core will require additional release of the module.
Best regards,
Artem Barger.
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Thu, 29 Sep 2016 11:48:29 +0100, Stian Soiland-Reyes wrote:
> Having all modules in the project have the same <version> is just a
> convention.
That's not what I've been told.
Anyways, I agree that interdependent modules _of the same project_
should preferably share the same version number.
> It could make sense to increment the rng-core module more slowly,
> while still allowing it in the build.
>
> For instance:
>
> commons-rng 1.2.0 could include:
> rng-core 1.1.2 (nothing actually changed, but we can't re-deploy
> 1.1.1)
> rng-utils 1.2.0 (new method)
>
> This is a very OSGi-way of doing it - but it will confuse lots of
> users as you know have three different version numbers and couldn't
> do
> ${rng.version}. For example - see how httpclient and httpcore have
> split apart version-wise - this can be confusing for many as you
> generally have to upgrade them together as close friends.
Confusing it is.
That's why my preferred option, by far, is to consider that
"rng-core" and "rng-utils" are independent projects, and that
"rng-utils" depends on "rng-core", in the same way that it
will depend on the JDK.
This would also reflect the separation of concern and the
quite possibly different developers teams.
This is a fairly sensitive issue: experience has shown that in
Commons Math, several parts of the library had, de facto, become
the personal turf of a single developer.
I believe that "component" implies an idea of strong integration
(down to the implementation level).
"Commons RNG" should not attempt to become "a framework that
produces random numbers", foremost because that is too vague a
definition for a "component".
Another reason is that it is too ambitious for non-experts (as all
the readers here are, AFAICT).
And yet another is that it exists already:
https://www.random.org/
"rng-utils" could very well depend on other libraries, if the
intention is really to provide extended support to non-Java and
non-Commons-RNG implementations.
What is called "rng-core" here would just happen to provide
pure-Java implementations (and the minimal set of utilities that
is now implemented), and the "UniformRandomProvider" interface.
>
>
> Another alternative would be a more careful hand-holding where
> rng-core stays versioned at 1.1.1 in the pom.xml until it changes,
> but
> then this is very hard to verify as you must make sure it is truly
> exactly the same as "the other 1.1.1". (And you would have to
> manually
> prune the "newer 1.1.1" from Nexus staging repository - if it even
> would allow you to upload a duplicate version).
This is fragile indeed.
>
>
> I would not recommend the option of 'partial module releases' - I've
> seen some Apache projects try to do this, but it leads to a very
> complicated picture for downstream as you then potentially have to
> build many different such "patch releases" to get all the modules. It
> also complicates our download/source pages a lot.
Agreed.
Two separate components would not suffer from that problem.
The release notes of "rng-utils" will mention the minimum
version of "rng-core" compatible with it, as it does for
the minimum version of the JDK.
It is of course possible that a release of "rng-core" could
trigger the release of "rng-utils", but only if the latter
would be broken by the former.
Breaking can only happen if
* methods are removed to the "UniformRandomProvider" interface,
* methods are added to the "UniformRandomProvider" interface,
* the name "UniformRandomProvider" is changed,
* the name "RandomSource" is changed,
* methods of "RandomSource" are removed,
* the external representation of the "RandomSource.State" is
modified.
I do not foresee any circumstance where any of those would
happen.
However, extend the scope of "Commons RNG" (e.g. to implementations
that would require adding methods in "UniformRandomProvider"), and
all bets are off...
> The simplest is to always increase the modules together - as we won't
> generally bump major. It does mean perceived incompatibility if appA
> uses rng-core 1.1.0 and friends; while a newer version of its
> dependencyB now uses rng-core 1.2.0 - and it could look like an
> upgrade is required even if rng-core 1.2.0 is line by line the same
> as
> rng-core 1.1.0
This is what I find unnecessary disturbing for user of
"rng-core" (i.e. all those applications who need a PRNG
in order use it in a specific way not covered by "rng-utils",
or those applications who want to minimize their dependencies
for whatever reasons).
For separate components, this disturbance does not happen.
Hence I find it a better solution.
>
> A good question is - if rng-core changes - would the other modules
> need to change as well?
Absolutely not (bugs notwithstanding).
It's exactly like when there is a new Java version, not all
libraries _need_ to use it (obviously none need to).
"rng-utils" can choose when it wants to release a version
that will use all the features of "rng-core".
This could happen if there is some ongoing work in "rng-utils"
that would better be completed before releasing the next version.
It is certainly acceptable that, for some period of time, a
new RNG implementation in "rng-core" will not be supported
by some of the (syntactic sugar) methods of "rng-utils".
Then again, it is not expected that "rng-core" will change
often, once most PRNGs have been implemented.
> If not, then there's not a big reason why they
> need to be together in the same project
My point indeed. ;-)
> (but we would end up with
> Commons Commons Components..)
There you lost me.
> BTW - we'll face a similar issue in Commons RDF where we shouldn't
> have to increase the version of the commons-rdf-api module when
> nothing has changed
This is indeed what I want to avoid if possible.
> - but would be forced to do so if we add a public
> method in one of the other modules (e.g. in the Jena integration) and
> release them all together.
Do I understand correctly that any "vendor" will force a re-release of
the common interface, whenever they touch their own code, and force a
"no-op" release of all the other vendors' library to keep the versions
the same?
Are there functionalities which a vendor might provide that does not
exist in "commons-rdf-api" and be used by applications?
If not, I'm not sure that the situation is comparable.
Gilles
>
>
> On 29 September 2016 at 11:23, Gilles <gi...@harfang.homelinux.org>
> wrote:
>> On Thu, 29 Sep 2016 12:06:36 +0200, Emmanuel Bourg wrote:
>>>
>>> Le 28/09/2016 � 15:58, Gilles a �crit :
>>>
>>>>> Multi-module projects are quite common and the case you mention
>>>>> isn't
>>>>> unusual.
>>>>
>>>>
>>>> Please show an example.
>>>
>>>
>>> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
>>> There is no lack of examples. Multi-module projects routinely
>>> publish
>>> new releases with some of their modules unmodified.
>>
>>
>> You noted several weeks ago that a Commons component cannot
>> release modules with different version numbers.
>>
>> The problem is not multi-module; it is two codebases (core
>> and utils) having completely independent release cycles.
>>
>> Users should be able to stick with "core-1.0", as long as
>> there is no change in that module, not forced to upgrade
>> to a "core-1.1" because a new release of "utils-1.1" was
>> performed.
>>
>>>
>>>
>>>> With modules, the problem I see is (as I already evoked it):
>>>>
>>>> At time t0, publish
>>>> * rng-core v1.1
>>>> * rng-utils v1.1
>>>>
>>>> Some time later, a weakness or bug that cannot be fixed
>>>> in backwards-compatible way is identified in "rg-utils".
>>>> Hence publish
>>>> * rng-core v2.0
>>>> * rng-utils v2.0
>>>>
>>>> Due to the package change, users that do NOT use "rng-utils" have
>>>> to either modify all their code because of the package name change
>>>> (although the implementation has not changed one bit) or continue
>>>> to use a now unsupported v1.1.
>>>
>>>
>>> True, but that's a very rare case, and there are other ways to
>>> mitigate
>>> what you perceive as an issue. If we decide in a couple of years to
>>> rework rng-utils in a backward incompatible way, we can rename or
>>> split
>>> it. For example let say we realize its scope isn't well defined or
>>> it
>>> gets too big, we could extract a "rng-variate" module and rename
>>> the
>>> remaining one to "rng-tools". This would not affect the users of
>>> rng-core.
>>
>>
>> Forced upgrade for no reason would not be a rare case:
>> Add a feature in "utils" and you force users of "core" to upgrade.
>> And the converse is also true.
>>
>>>
>>>> Just to spare one vote every two years?
>>>
>>>
>>> And multiple projects would hypothetically ease one migration every
>>> five
>>> years?
>>
>>
>> This would happen for _every_ release.
>>
>> Gilles
>>
>>
>>>
>>> Emmanuel Bourg
>>>
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Stian Soiland-Reyes <st...@apache.org>.
Having all modules in the project have the same <version> is just a convention.
It could make sense to increment the rng-core module more slowly,
while still allowing it in the build.
For instance:
commons-rng 1.2.0 could include:
rng-core 1.1.2 (nothing actually changed, but we can't re-deploy 1.1.1)
rng-utils 1.2.0 (new method)
This is a very OSGi-way of doing it - but it will confuse lots of
users as you know have three different version numbers and couldn't do
${rng.version}. For example - see how httpclient and httpcore have
split apart version-wise - this can be confusing for many as you
generally have to upgrade them together as close friends.
Another alternative would be a more careful hand-holding where
rng-core stays versioned at 1.1.1 in the pom.xml until it changes, but
then this is very hard to verify as you must make sure it is truly
exactly the same as "the other 1.1.1". (And you would have to manually
prune the "newer 1.1.1" from Nexus staging repository - if it even
would allow you to upload a duplicate version).
I would not recommend the option of 'partial module releases' - I've
seen some Apache projects try to do this, but it leads to a very
complicated picture for downstream as you then potentially have to
build many different such "patch releases" to get all the modules. It
also complicates our download/source pages a lot.
The simplest is to always increase the modules together - as we won't
generally bump major. It does mean perceived incompatibility if appA
uses rng-core 1.1.0 and friends; while a newer version of its
dependencyB now uses rng-core 1.2.0 - and it could look like an
upgrade is required even if rng-core 1.2.0 is line by line the same as
rng-core 1.1.0
A good question is - if rng-core changes - would the other modules
need to change as well? If not, then there's not a big reason why they
need to be together in the same project (but we would end up with
Commons Commons Components..)
BTW - we'll face a similar issue in Commons RDF where we shouldn't
have to increase the version of the commons-rdf-api module when
nothing has changed - but would be forced to do so if we add a public
method in one of the other modules (e.g. in the Jena integration) and
release them all together.
On 29 September 2016 at 11:23, Gilles <gi...@harfang.homelinux.org> wrote:
> On Thu, 29 Sep 2016 12:06:36 +0200, Emmanuel Bourg wrote:
>>
>> Le 28/09/2016 à 15:58, Gilles a écrit :
>>
>>>> Multi-module projects are quite common and the case you mention isn't
>>>> unusual.
>>>
>>>
>>> Please show an example.
>>
>>
>> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
>> There is no lack of examples. Multi-module projects routinely publish
>> new releases with some of their modules unmodified.
>
>
> You noted several weeks ago that a Commons component cannot
> release modules with different version numbers.
>
> The problem is not multi-module; it is two codebases (core
> and utils) having completely independent release cycles.
>
> Users should be able to stick with "core-1.0", as long as
> there is no change in that module, not forced to upgrade
> to a "core-1.1" because a new release of "utils-1.1" was
> performed.
>
>>
>>
>>> With modules, the problem I see is (as I already evoked it):
>>>
>>> At time t0, publish
>>> * rng-core v1.1
>>> * rng-utils v1.1
>>>
>>> Some time later, a weakness or bug that cannot be fixed
>>> in backwards-compatible way is identified in "rg-utils".
>>> Hence publish
>>> * rng-core v2.0
>>> * rng-utils v2.0
>>>
>>> Due to the package change, users that do NOT use "rng-utils" have
>>> to either modify all their code because of the package name change
>>> (although the implementation has not changed one bit) or continue
>>> to use a now unsupported v1.1.
>>
>>
>> True, but that's a very rare case, and there are other ways to mitigate
>> what you perceive as an issue. If we decide in a couple of years to
>> rework rng-utils in a backward incompatible way, we can rename or split
>> it. For example let say we realize its scope isn't well defined or it
>> gets too big, we could extract a "rng-variate" module and rename the
>> remaining one to "rng-tools". This would not affect the users of rng-core.
>
>
> Forced upgrade for no reason would not be a rare case:
> Add a feature in "utils" and you force users of "core" to upgrade.
> And the converse is also true.
>
>>
>>> Just to spare one vote every two years?
>>
>>
>> And multiple projects would hypothetically ease one migration every five
>> years?
>
>
> This would happen for _every_ release.
>
> Gilles
>
>
>>
>> Emmanuel Bourg
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 29/09/2016 � 12:23, Gilles a �crit :
>> And multiple projects would hypothetically ease one migration every five
>> years?
>
> This would happen for _every_ release.
How do you come to this conclusion? We are talking about an incompatible
update, the kind of update that forces to change the name of the base
package and the Maven GAV. This doesn't happen for every release.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 29 Sep 2016 12:06:36 +0200, Emmanuel Bourg wrote:
> Le 28/09/2016 � 15:58, Gilles a �crit :
>
>>> Multi-module projects are quite common and the case you mention
>>> isn't
>>> unusual.
>>
>> Please show an example.
>
> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
> There is no lack of examples. Multi-module projects routinely publish
> new releases with some of their modules unmodified.
You noted several weeks ago that a Commons component cannot
release modules with different version numbers.
The problem is not multi-module; it is two codebases (core
and utils) having completely independent release cycles.
Users should be able to stick with "core-1.0", as long as
there is no change in that module, not forced to upgrade
to a "core-1.1" because a new release of "utils-1.1" was
performed.
>
>
>> With modules, the problem I see is (as I already evoked it):
>>
>> At time t0, publish
>> * rng-core v1.1
>> * rng-utils v1.1
>>
>> Some time later, a weakness or bug that cannot be fixed
>> in backwards-compatible way is identified in "rg-utils".
>> Hence publish
>> * rng-core v2.0
>> * rng-utils v2.0
>>
>> Due to the package change, users that do NOT use "rng-utils" have
>> to either modify all their code because of the package name change
>> (although the implementation has not changed one bit) or continue
>> to use a now unsupported v1.1.
>
> True, but that's a very rare case, and there are other ways to
> mitigate
> what you perceive as an issue. If we decide in a couple of years to
> rework rng-utils in a backward incompatible way, we can rename or
> split
> it. For example let say we realize its scope isn't well defined or it
> gets too big, we could extract a "rng-variate" module and rename the
> remaining one to "rng-tools". This would not affect the users of
> rng-core.
Forced upgrade for no reason would not be a rare case:
Add a feature in "utils" and you force users of "core" to upgrade.
And the converse is also true.
>
>> Just to spare one vote every two years?
>
> And multiple projects would hypothetically ease one migration every
> five
> years?
This would happen for _every_ release.
Gilles
>
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 30 Sep 2016 10:45:47 -0500, Brent Worden wrote:
> On Fri, Sep 30, 2016 at 10:02 AM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
>>
>>>
>>> - No immediate Jenkins feedback if a rng-core change breaks
>>> rng-utils
>
>>
>> I'm not sure I got that one.
>> If it means to copy the new "rng-core" over to some place for use
>> by the build of "rng-utils", can't this be done by a "post-build"
>> script?
>
>
> The lack of immediate feedback is the same risk we have with other
> commons
> components being dependencies of other projects, Apache or otherwise.
> I
> think with the level that commons projects are policed through unit
> tests,
> code reviews, backwards compatibility checks, and release candidate
> reviews
> this risk is mitigated to a very acceptable level.
>
> In the past when the commons project changes did cause unintended
> upstream
> problems, I feel we have done a good job reacting in a timely fashion
> to
> address these issues and make process improvements if warranted. I
> do see
> how we'd be any different, or need to be any different, with these
> two
> components.
>
> If this is something we want more risk mitigation, we could set up
> both
> components in Gump.
>
>
>
>> If that is not obvious to you, but are willing to trust other
>> members here (me in this case), you could agree to make the
>> experiment! :-)
>> Then when we see more code, more users, more contributors,
>> more opinions, and we see that there is merit in merging the
>> two components, we'll just do it.
>> [And I'll apologize to the INFRA people for the time they wasted
>> in setting up the project.]
>>
>>
>> Gilles
>>
>>
> I was just thinking the same thing. Let's try one way and see it
> works to
> satisfaction. If it does, great. If it proves to be burdensome or
> the
> benefits are not realized, we can try another approach.
>
> Another thing I was thinking if we wanted to test drive the
> multi-project
> route, what about setting up rng-utils in the sandbox? Process-wise
> it
> would be a lot like a proper project thus, giving us the opportunity
> to see
> how it would actually function. One benefit of using the sandbox is
> that
> the work can begin immediately as it does not require infrastructure
> changes.
Good.
Let's start solving problems, real or perceived.
Gilles
> Brent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Gary Gregory <ga...@gmail.com>.
Hi All,
[Note my careful use of the terms "project", "component", and "module"]
Pardon my jumping in late... If some of this is leading to more than one
commons-rng component within Apache Commons, I would be against that; Maven
modules are a perfect match for this concept.
Please allow me to relate my experience with Apache Log4j 2 where we have
one project with 26 modules (granted there are 8 non-production modules:
samples and benchmarks). For most releases, there are interesting and
significant changes in only one module (log4j-core). A Log4j 2 release
means a release of all modules and a guarantee that all modules work
together (of course).
Another example is Apache HttpComponets where there are several components
and some components have several modules. This is not a trivial environment
to set up as a project developer (unless I made a mess of my own personal
set up, not unlikely! ;-)
So far, Commons-RNG is a small and focused component related in theme to
Commons-Math but these are not dependent on each other, so we have to keep
that explanation clear.
I would think that it would be better to have modules potentially come,
morph, go, within one component.
3c,
Gary
On Fri, Sep 30, 2016 at 8:45 AM, Brent Worden <br...@gmail.com>
wrote:
> On Fri, Sep 30, 2016 at 10:02 AM, Gilles <gi...@harfang.homelinux.org>
> wrote:
>
> > On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
> >
> >>
> >> - No immediate Jenkins feedback if a rng-core change breaks rng-utils
>
> >
> > I'm not sure I got that one.
> > If it means to copy the new "rng-core" over to some place for use
> > by the build of "rng-utils", can't this be done by a "post-build"
> > script?
>
>
> The lack of immediate feedback is the same risk we have with other commons
> components being dependencies of other projects, Apache or otherwise. I
> think with the level that commons projects are policed through unit tests,
> code reviews, backwards compatibility checks, and release candidate reviews
> this risk is mitigated to a very acceptable level.
>
> In the past when the commons project changes did cause unintended upstream
> problems, I feel we have done a good job reacting in a timely fashion to
> address these issues and make process improvements if warranted. I do see
> how we'd be any different, or need to be any different, with these two
> components.
>
> If this is something we want more risk mitigation, we could set up both
> components in Gump.
>
>
>
> > If that is not obvious to you, but are willing to trust other
> > members here (me in this case), you could agree to make the
> > experiment! :-)
> > Then when we see more code, more users, more contributors,
> > more opinions, and we see that there is merit in merging the
> > two components, we'll just do it.
> > [And I'll apologize to the INFRA people for the time they wasted
> > in setting up the project.]
> >
> >
> > Gilles
> >
> >
> I was just thinking the same thing. Let's try one way and see it works to
> satisfaction. If it does, great. If it proves to be burdensome or the
> benefits are not realized, we can try another approach.
>
> Another thing I was thinking if we wanted to test drive the multi-project
> route, what about setting up rng-utils in the sandbox? Process-wise it
> would be a lot like a proper project thus, giving us the opportunity to see
> how it would actually function. One benefit of using the sandbox is that
> the work can begin immediately as it does not require infrastructure
> changes.
>
> Brent
>
--
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: [RNG] modules vs projects
Posted by Brent Worden <br...@gmail.com>.
On Fri, Sep 30, 2016 at 10:02 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
>
>>
>> - No immediate Jenkins feedback if a rng-core change breaks rng-utils
>
> I'm not sure I got that one.
> If it means to copy the new "rng-core" over to some place for use
> by the build of "rng-utils", can't this be done by a "post-build"
> script?
The lack of immediate feedback is the same risk we have with other commons
components being dependencies of other projects, Apache or otherwise. I
think with the level that commons projects are policed through unit tests,
code reviews, backwards compatibility checks, and release candidate reviews
this risk is mitigated to a very acceptable level.
In the past when the commons project changes did cause unintended upstream
problems, I feel we have done a good job reacting in a timely fashion to
address these issues and make process improvements if warranted. I do see
how we'd be any different, or need to be any different, with these two
components.
If this is something we want more risk mitigation, we could set up both
components in Gump.
> If that is not obvious to you, but are willing to trust other
> members here (me in this case), you could agree to make the
> experiment! :-)
> Then when we see more code, more users, more contributors,
> more opinions, and we see that there is merit in merging the
> two components, we'll just do it.
> [And I'll apologize to the INFRA people for the time they wasted
> in setting up the project.]
>
>
> Gilles
>
>
I was just thinking the same thing. Let's try one way and see it works to
satisfaction. If it does, great. If it proves to be burdensome or the
benefits are not realized, we can try another approach.
Another thing I was thinking if we wanted to test drive the multi-project
route, what about setting up rng-utils in the sandbox? Process-wise it
would be a lot like a proper project thus, giving us the opportunity to see
how it would actually function. One benefit of using the sandbox is that
the work can begin immediately as it does not require infrastructure
changes.
Brent
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
> Le 29/09/2016 � 13:59, Gilles a �crit :
>
>> What you are arguing here is that if "some-lib" is
>> upgraded, then the JDK must change version too!
>>
>> Does that (extreme) comparison make the issue clearer?
>
> No, because it isn't comparable to our situation. rng-core and
> rng-utils
> are developed by the same team and target the same field (random
> number
> generation and its direct applications). The JDK and "some-lib" are
> completely unrelated.
"some-lib" uses the JDK
just as
"rng-utils" uses "rng-core"
The comparison is adequate, if you consider the examples I've given
(avoiding upgrades when no code change happened).
>> I agree that the mixing of versions, even if allowed,
>> is not the best choice; that's why I've argued from the
>> outset that such loosely coupled modules must in fact
>> be different components!
>>
>> The result will be that, indeed, users must choose from
>> compatible versions. Anything new under the Sun?
>
> As mentioned by Stian this is how work httpcore and httpclient, and
> this
> can be confusing and error prone. If the modules are all aligned on
> the
> same version the users have only one version to update (typically
> with a
> Maven/Gradle property) and there is no risk of version mismatch.
I don't deny that tools such as maven or ivy can download a new
version automatically.
Nevertheless, I envision that "rng-core" will change at much slower
pace that "rng-utils", many such upgrades will download the exact
same code.
Also, contrarily to what Artem suggested, I also envision that
most of "rng-core" will change in a compatible way (e.g. add
new RNG implementations), so that "rng-utils" does not need to
be released in sync.
Yes, for some time, users of the syntactic sugar factory won't
be able to use it in order to instantiate the new RNG. So what?
[How is that different from a library sticking to Java 6, and
thus cannot use the features of Java 8?]
>> Can we please go away from the monolithic culture (and
>> look at what other libraries do, and at what IIUC the
>> JDK is going to do in the next major release)?
>
> By definition a modular structure isn't monolithic, that's exactly
> what
> other libraries do. And it isn't incompatible with the Java 9
> modules.
I'm all for modular structure, but against unnecessary dependence
of release cycles.
They are two different things.
In the examples you gave, I could certainly trust you that a
release cycle dependency exist.
I don't see that in my vision of "rng-core" and "rng-utils".
>> It seems like the number of components were a limited
>> resource. This kind of conversation is truly wasting
>> valuable time that could have been better spent in setting
>> up "rng-utils".
>>
>> It seems like folks here are happy to make things more
>> complex than they intrinsically are.
>
> Let's talk about complexity. Separate projects mean:
> - Extra work for the infra team to setup the project
Thanks to all people giving time!
INFRA people will create this repository when it suits them.
Then I (and you) will save huge amounts of time because we
won't have to fight over what goes where, thanks to well-scoped
components and separation of concern.
> - Users must carefully pick the compatible versions for the projects
Same as any application does already.
> - JIRA reports are likely to be mixed (RNG issues reported in
> RNGUTILS
> and vice versa)
Perhaps.
I'll move them. OK? ;-)
> - Extra release management work
I'll do it. OK?
> - Extra project maintenance (parent and dependencies updates, etc)
I'll do it. OK?
> - Extra filter rules to setup for the people subscribed to the ML
Go complain to the PMC.
[I'm all for separate MLs, as people have been recurrently
proposing.]
> - No immediate Jenkins feedback if a rng-core change breaks rng-utils
I'm not sure I got that one.
If it means to copy the new "rng-core" over to some place for use
by the build of "rng-utils", can't this be done by a "post-build"
script?
> That doesn't look easier than one multi-module project to me.
You are mixing tools issues (which we can address as I just did
above) with principle: Whether "rng-core" and "rng-utils" are
sufficiently interdependent to make them part of a single
codebase. If not (my POV), then managing them together is
more complex (because there is factually more ways to break
something).
If that is not obvious to you, but are willing to trust other
members here (me in this case), you could agree to make the
experiment! :-)
Then when we see more code, more users, more contributors,
more opinions, and we see that there is merit in merging the
two components, we'll just do it.
[And I'll apologize to the INFRA people for the time they wasted
in setting up the project.]
Deal?
Gilles
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 29/09/2016 � 13:59, Gilles a �crit :
> What you are arguing here is that if "some-lib" is
> upgraded, then the JDK must change version too!
>
> Does that (extreme) comparison make the issue clearer?
No, because it isn't comparable to our situation. rng-core and rng-utils
are developed by the same team and target the same field (random number
generation and its direct applications). The JDK and "some-lib" are
completely unrelated.
> I agree that the mixing of versions, even if allowed,
> is not the best choice; that's why I've argued from the
> outset that such loosely coupled modules must in fact
> be different components!
>
> The result will be that, indeed, users must choose from
> compatible versions. Anything new under the Sun?
As mentioned by Stian this is how work httpcore and httpclient, and this
can be confusing and error prone. If the modules are all aligned on the
same version the users have only one version to update (typically with a
Maven/Gradle property) and there is no risk of version mismatch.
> Can we please go away from the monolithic culture (and
> look at what other libraries do, and at what IIUC the
> JDK is going to do in the next major release)?
By definition a modular structure isn't monolithic, that's exactly what
other libraries do. And it isn't incompatible with the Java 9 modules.
> It seems like the number of components were a limited
> resource. This kind of conversation is truly wasting
> valuable time that could have been better spent in setting
> up "rng-utils".
>
> It seems like folks here are happy to make things more
> complex than they intrinsically are.
Let's talk about complexity. Separate projects mean:
- Extra work for the infra team to setup the project
- Users must carefully pick the compatible versions for the projects
- JIRA reports are likely to be mixed (RNG issues reported in RNGUTILS
and vice versa)
- Extra release management work
- Extra project maintenance (parent and dependencies updates, etc)
- Extra filter rules to setup for the people subscribed to the ML
- No immediate Jenkins feedback if a rng-core change breaks rng-utils
That doesn't look easier than one multi-module project to me.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 29 Sep 2016 13:40:08 +0300, Artem Barger wrote:
> \u200bHi,
What you are arguing here is that if "some-lib" is
upgraded, then the JDK must change version too!
Does that (extreme) comparison make the issue clearer?
I agree that the mixing of versions, even if allowed,
is not the best choice; that's why I've argued from the
outset that such loosely coupled modules must in fact
be different components!
The result will be that, indeed, users must choose from
compatible versions. Anything new under the Sun?
Can we please go away from the monolithic culture (and
look at what other libraries do, and at what IIUC the
JDK is going to do in the next major release)?
It seems like the number of components were a limited
resource. This kind of conversation is truly wasting
valuable time that could have been better spent in setting
up "rng-utils".
It seems like folks here are happy to make things more
complex than they intrinsically are.
Gilles
\u200b
>
> On Thu, Sep 29, 2016 at 1:06 PM, Emmanuel Bourg <eb...@apache.org>
> wrote:
>
>>
>> >> Multi-module projects are quite common and the case you mention
>> isn't
>> >> unusual.
>> >
>> > Please show an example.
>>
>> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
>> There is no lack of examples. Multi-module projects routinely
>> publish
>> new releases with some of their modules unmodified.
>
>
> I think that I'd agree w/ Emmanuel here. It will be very strange
> where
> on change in rng-core from v1 to v2 one will have to update
> rng-module1
> from v1 to v2 (since I believe that rng-module1 will depend on
> rng-core),
> while
> version update of rng-module1 will not cause reciprocal effect.
>
> IMO it's much easier when user will be able to use one version for
> all
> rng-* modules,
> rather than starting to struggle what version need to be taken for
> what
> module.
>
>
> <dependency>
> <groupId>org.apache.commons</groupId>
> <artifactId>rng-core</artifactId>
> <version>${rng.version}</version>
> </dependency>
>
> <dependency>
> <groupId>org.apache.commons</groupId>
> <artifactId>rng-tools</artifactId>
> <version>${rng.version}</version>
> </dependency>
>
> Looks better than
>
> <dependency>
> <groupId>org.apache.commons</groupId>
> <artifactId>rng-core</artifactId>
> <version>v1</version>
> </dependency>
>
> <dependency>
> <groupId>org.apache.commons</groupId>
> <artifactId>rng-tools</artifactId>
> <version>v99</version>
> </dependency>
>
> And it's much easier to support.
>
> Best regards,
> Artem Barger.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Artem Barger <ar...@bargr.net>.
Hi,
On Thu, Sep 29, 2016 at 1:06 PM, Emmanuel Bourg <eb...@apache.org> wrote:
>
> >> Multi-module projects are quite common and the case you mention isn't
> >> unusual.
> >
> > Please show an example.
>
> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
> There is no lack of examples. Multi-module projects routinely publish
> new releases with some of their modules unmodified.
I think that I'd agree w/ Emmanuel here. It will be very strange where
on change in rng-core from v1 to v2 one will have to update rng-module1
from v1 to v2 (since I believe that rng-module1 will depend on rng-core),
while
version update of rng-module1 will not cause reciprocal effect.
IMO it's much easier when user will be able to use one version for all
rng-* modules,
rather than starting to struggle what version need to be taken for what
module.
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>rng-core</artifactId>
<version>${rng.version}</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>rng-tools</artifactId>
<version>${rng.version}</version>
</dependency>
Looks better than
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>rng-core</artifactId>
<version>v1</version>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>rng-tools</artifactId>
<version>v99</version>
</dependency>
And it's much easier to support.
Best regards,
Artem Barger.
Re: [RNG] modules vs projects
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2016 � 15:58, Gilles a �crit :
>> Multi-module projects are quite common and the case you mention isn't
>> unusual.
>
> Please show an example.
Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
There is no lack of examples. Multi-module projects routinely publish
new releases with some of their modules unmodified.
> With modules, the problem I see is (as I already evoked it):
>
> At time t0, publish
> * rng-core v1.1
> * rng-utils v1.1
>
> Some time later, a weakness or bug that cannot be fixed
> in backwards-compatible way is identified in "rg-utils".
> Hence publish
> * rng-core v2.0
> * rng-utils v2.0
>
> Due to the package change, users that do NOT use "rng-utils" have
> to either modify all their code because of the package name change
> (although the implementation has not changed one bit) or continue
> to use a now unsupported v1.1.
True, but that's a very rare case, and there are other ways to mitigate
what you perceive as an issue. If we decide in a couple of years to
rework rng-utils in a backward incompatible way, we can rename or split
it. For example let say we realize its scope isn't well defined or it
gets too big, we could extract a "rng-variate" module and rename the
remaining one to "rng-tools". This would not affect the users of rng-core.
> Just to spare one vote every two years?
And multiple projects would hypothetically ease one migration every five
years?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Gilles <gi...@harfang.homelinux.org>.
On Wed, 28 Sep 2016 14:17:19 +0200, Emmanuel Bourg wrote:
> Le 27/09/2016 � 01:14, Gilles a �crit :
>
>> An additional module in Commons RNG will not help, as was noticed
>> some time ago: it won't be possible/allowed to release the modules
>> separately.
>>
>> I don't want to have to release a major version of Commons RNG
>> just because accessory tools requires it.
>> Users should not wonder with each new version whether there was
>> a bug or a change in the core functionality.
>
> Multi-module projects are quite common and the case you mention isn't
> unusual.
Please show an example.
> I don't think this is a blocking issue. Even if only one of the
> modules has changed it's possible to publish a new release.
With modules, the problem I see is (as I already evoked it):
At time t0, publish
* rng-core v1.1
* rng-utils v1.1
Some time later, a weakness or bug that cannot be fixed
in backwards-compatible way is identified in "rg-utils".
Hence publish
* rng-core v2.0
* rng-utils v2.0
Due to the package change, users that do NOT use "rng-utils" have
to either modify all their code because of the package name change
(although the implementation has not changed one bit) or continue
to use a now unsupported v1.1.
> And if all
> modules evolve continuously a few release processes are saved
> compared
> to a multi-project approach.
The point is that "rng-core" is not meant to evolve continuously
(as you pointed out yourself, noticing the limited number of RNG
implementations out there!).
When "rng-core" evolves, it is in order to add implementations: a
backward compatible operation that does not require a major version
bump.
Each major bump will rightly trigger unrest among users. And
unnecessary work.
Just to spare one vote every two years? [1]
Moreover even if they could change, "rng-core" and "rng-utils"
will only rarely "co-evolve" since
* adding new RNGs to the former has zero impact on the latter,
* adding new utilities to the latter has zero impact on the
former.
Moreover, _old_ versions of "rng-utils" could perfectly use
_new_ versions of "rng-core".
With modules, you'd have to re-release "rng-utils", again for
nothing.
So I would readily bet that a multi-module project will imply
MORE time from the RM and from the voters.
It's always possible to merge two projects and harmonize the
package name and version number.
One the major bump has been done, for no reason (as I showed
above), it cannot be undone.
Gilles
[1] Wild guess at the average release rate of a Commons component.
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] modules vs projects
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 27/09/2016 � 01:14, Gilles a �crit :
> An additional module in Commons RNG will not help, as was noticed
> some time ago: it won't be possible/allowed to release the modules
> separately.
>
> I don't want to have to release a major version of Commons RNG
> just because accessory tools requires it.
> Users should not wonder with each new version whether there was
> a bug or a change in the core functionality.
Multi-module projects are quite common and the case you mention isn't
unusual. I don't think this is a blocking issue. Even if only one of the
modules has changed it's possible to publish a new release. And if all
modules evolve continuously a few release processes are saved compared
to a multi-project approach.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] Scope of "Commons RNG"
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 27 Sep 2016 00:37:26 +0200, Emmanuel Bourg wrote:
> Le 26/09/2016 � 18:33, Gilles a �crit :
>
>> As I suggested previously on this list, I'm going to request
>> a new "git" repository for implementing utilities based on
>> random generators.
>
> I suggest waiting until RNG 1.0 is out and we have a clearer view of
> the
> scope of the components. We can still experiment with "rng-tools" on
> a
> separate branch or with a Maven module in the same repository.
My point is that we don't have a clear view.
An additional module in Commons RNG will not help, as was noticed
some time ago: it won't be possible/allowed to release the modules
separately.
I don't want to have to release a major version of Commons RNG
just because accessory tools requires it.
Users should not wonder with each new version whether there was
a bug or a change in the core functionality.
Morevover, as an example, you don't seem to like my choice of
factory. Adding layers and tools in the same component will
multiply the discussions about taste and mileage to no end.
As there was in CM. As it happens now.
Another git repository will avoid that temptation.
>> First candidates are:
>> * Non-uniform deviates (i.e. the samplers now defined in
>> Commons Math's "o.a.c.math4.distribution" package),
>
> I agree this doesn't belong to commons-rng, but I'm not convinced it
> would fit a commons-rng-tools component. Maybe a component more
> targeted
> toward statistic algorithms?
Sampling and statistics do not necessarily belong together.
[This was a discussion in CM.]
But sampling is a direct use of RNG.
>> * 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.
>> * Data generation (e.g. random strings, currently defined in
>> Commons Math's "o.a.c.m.random.RandomUtils"),
>
> I'm not familiar with this, it looks linked to the distribution
> stuff.
No, it contains code that was previously in the "RandomDataGenerator"
class; that latter class indeed used to duplicate the sampling
utilities
in the CM "distribution" package.
It also contains functionality that was also developed in Commons Lang.
And generation of hexadecimal string, and picking randomly from a
Collection, etc.
>> * Syntactic sugar (e.g. strongly-type factory methods, as
>> suggested by Emmanuel during the RC1 vote),
>
> Having two different factories in two different components for the
> same
> objects is odd. I prefer only one factory.
So be it; there is one.
I was trying to take care of your use-case.
I think that it is fine to wrap "my" factory into another
offered as syntactic sugar to allow an intelligent IDE
to do its job.
>> * Bridge/wrappers (as suggested by Emmanuel in RNG-19, on JIRA).
>
> A mere random generator should be in commons-rng.
Wrapping "/dev/random" is out of scope: it is not a mere random
generator.
Scope is: algorithms implemented in Java, in Commons RNG, all
providing the same basic functionality (like save/restore).
> And the
> java.util.Random bridge also belongs to commons-rng in my opinion,
> that's similar to the methods converting from/to java.util.Properties
> in
> commons-configuration.
As said, the view is not clear; this is not core functionality
(cf. above), it is convenience/utility.
We have to ask questions and provide convincing answers _before_
adding potentially useless code.
What are use-cases for "RandomSource.JDK"?
Gilles
> Emmanuel Bourg
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] Scope of "Commons RNG"
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 26/09/2016 � 18:33, Gilles a �crit :
> As I suggested previously on this list, I'm going to request
> a new "git" repository for implementing utilities based on
> random generators.
I suggest waiting until RNG 1.0 is out and we have a clearer view of the
scope of the components. We can still experiment with "rng-tools" on a
separate branch or with a Maven module in the same repository.
> First candidates are:
> * Non-uniform deviates (i.e. the samplers now defined in
> Commons Math's "o.a.c.math4.distribution" package),
I agree this doesn't belong to commons-rng, but I'm not convinced it
would fit a commons-rng-tools component. Maybe a component more targeted
toward statistic algorithms?
> * 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.
> * Data generation (e.g. random strings, currently defined in
> Commons Math's "o.a.c.m.random.RandomUtils"),
I'm not familiar with this, it looks linked to the distribution stuff.
> * Syntactic sugar (e.g. strongly-type factory methods, as
> suggested by Emmanuel during the RC1 vote),
Having two different factories in two different components for the same
objects is odd. I prefer only one factory.
> * Bridge/wrappers (as suggested by Emmanuel in RNG-19, on JIRA).
A mere random generator should be in commons-rng. And the
java.util.Random bridge also belongs to commons-rng in my opinion,
that's similar to the methods converting from/to java.util.Properties in
commons-configuration.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] java.util.Random vs independent interface
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 28/09/2016 � 14:59, Gilles a �crit :
> This will lead to unexpected behaviour.
> For example, calling "setSeed" on the returned "Random" instance,
> will have no effect.
>
> This will generate bug reports that can't be fixed without
> resorting to very ugly workaround that have nothing to do with
> the RNG functionality.
I agree the setSeed method is embarrassing when java.util.Random is
considered as an interface, but we can simply choose to ignore it and
throw an UnsupportedOperationException. I don't think reseeding a
generator is a common use case anyway.
If we compare the public API of java.util.Random and
UniformRandomProvider they mostly share the same methods, minus setSeed
(and nextGaussian but that's another story). The only reason justifying
the existence of UniformRandomProvider is the removal of setSeed. I
don't think removing this method is important enough to sacrifice the
compatibility with java.util.Random.
I agree that in an ideal world the JDK should provide a well defined
random interface that could be extended to fulfill any need. Or we could
adopt a NIH attitude, vow to design purity, and define our own. But
that's not a pragmatic choice. java.util.Random is already used in the
wild, and the smart move is to leverage its ubiquity.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] Scope of "Commons RNG"
Posted by Gilles <gi...@harfang.homelinux.org>.
On Tue, 27 Sep 2016 20:07:19 -0500, Brent Worden wrote:
> On Mon, Sep 26, 2016 at 11:36 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Mon, 26 Sep 2016 21:23:24 -0500, Brent Worden wrote:
>>
>>>
>>> With that said, I started thinking a bridge to go between the two
>>> engines,
>>> UniformRandomProvider and java.util.Random, might be beneficial.
>>> For
>>> third
>>> parties that have implemented java.util.Random subclasses, it would
>>> be
>>> nice
>>> to provide the means to easily adapt their Random implementation to
>>> a
>>> UniformRandomProvider so it can be used in commons-rng related
>>> code.
>>>
>>
>> Like method "asUniformRandomProvider" in
>> "o.a.c.math4.random.RandomUtils"
>> ("master" branch)?
>>
>>
> Yes, that is exactly what I was thinking.
>
>
>
>> Conversely, for third parties that use java.util.Random instances,
>> it would
>>> be nice to easily adapt a UniformRandomProvider to a Random so the
>>> commons-rng generators could be used.
>>>
>>
>> That would be possible (but the bridge must be from "RandomSource",
>> not "UniformRandomProvider"): see class
>> "o.a.c.math4.random.RngAdaptor".
>>
>> Gilles
>>
>>
> Why RandomSource? I was thinking a reciprocal method to the above:
>
> public static Random asRandom(UnifiedRandomProvider urp) {
> return new Random() {
> @Override
> protected int next(int bits) {
> ...
> }
> };
> }
This will lead to unexpected behaviour.
For example, calling "setSeed" on the returned "Random" instance,
will have no effect.
This will generate bug reports that can't be fixed without
resorting to very ugly workaround that have nothing to do with
the RNG functionality.
Here, and in your other message you want "Random" to assume a
greater role which it was never meant too.
Ever wondered why there is no "Random" interface?
It cannot be a bridge because it's too specialized, with assumptions
(and consequent implementations) that do not hold generally.
The ability to extend it, is misleading, and useless beyond trivial
cases (such as tracing code execution maybe).
You should take Random as it is: a specific LCG that is totally
outdated.
It is disappointing that Apache, as a purported leader in Java
software development, would, in 2016, still advertize using such
classes despite the existence of better alternatives.
It is also quite discouraging that when someone spends time to
try and renew the POV of this community on some issue[1], it is
mostly met with distrust.
I, too, find it disturbing that some parts of the JDK might not
be the reference one thinks it should be; and I want to assume
that this fact concerns only a tiny part of the JDK.
But "java.util.Random" is one case in point; using it as an
interface is not a good idea IMO.[2]
Gilles
[1] Just conveying knowledge found elsewhere (and designing code
based on it).
[2] Other Java RNG codes have chosen that path. "Commons RNG"
was designed so that a _choice_ exists.
What users will select is up to them.
>
> Brent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] Scope of "Commons RNG"
Posted by Brent Worden <br...@gmail.com>.
On Mon, Sep 26, 2016 at 11:36 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Mon, 26 Sep 2016 21:23:24 -0500, Brent Worden wrote:
>
>>
>> With that said, I started thinking a bridge to go between the two engines,
>> UniformRandomProvider and java.util.Random, might be beneficial. For
>> third
>> parties that have implemented java.util.Random subclasses, it would be
>> nice
>> to provide the means to easily adapt their Random implementation to a
>> UniformRandomProvider so it can be used in commons-rng related code.
>>
>
> Like method "asUniformRandomProvider" in "o.a.c.math4.random.RandomUtils"
> ("master" branch)?
>
>
Yes, that is exactly what I was thinking.
> Conversely, for third parties that use java.util.Random instances, it would
>> be nice to easily adapt a UniformRandomProvider to a Random so the
>> commons-rng generators could be used.
>>
>
> That would be possible (but the bridge must be from "RandomSource",
> not "UniformRandomProvider"): see class "o.a.c.math4.random.RngAdaptor".
>
> Gilles
>
>
Why RandomSource? I was thinking a reciprocal method to the above:
public static Random asRandom(UnifiedRandomProvider urp) {
return new Random() {
@Override
protected int next(int bits) {
...
}
};
}
Brent
Re: [RNG] Scope of "Commons RNG"
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 26 Sep 2016 21:23:24 -0500, Brent Worden wrote:
> On Mon, Sep 26, 2016 at 6:21 PM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> On Mon, 26 Sep 2016 16:10:12 -0500, Brent Worden wrote:
>>
>>> I would keep the JDK source. My reasoning being:
>>>
>>> 1. Users that want to use java.util.Random would not be able to use
>>> some
>>> or
>>> all of the RNG Utils code as the later will probably relay on
>>> RandomSource
>>> instances.
>>>
>>
>> I don't understand the above.
>> Could you provide an example of what should be, but won't
>> be possible?
>>
> I misspoke when I stated RandomSource. The RNG Utils code will
> probably
> rely on UniformRandomProvider as its engine for random numbers. So,
> if I
> wanted to use java.util.Random as the engine I was thinking to use
> the JDK
> random source to create the equivalent UniformRandomProvider. I
> believe
> what you are suggesting is if I wanted OOTB java.util.Random behavior
> I
> would create the equivalent LCG based UniformRandomProvider (once
> said
> functionality is available in commons-rng). I guess that is
> acceptable if
> such a UniformRandomProvider creation is in the form of a
> convenience,
> factory method so I am not required to know the correct LCG
> parameters to
> use.
If the need is to generate the same sequence of integers as would be
generated by "Random", then, indeed an LCG with the appropriate
settings
(multiplier, increment, modulus) should fill the bill.
A custom LCG would be instantiated with a call like
rng = RandomSource.create(RandomSource.LCG_SELECT, seed, multiplier,
increment, modulus);
and convenience shortcut would be provided as
rng = RandomSource.create(RandomSource.LCG_JDK, seed);
> 2. With LCGs the current Random implementation provided by Oracle
> could
>>> possibly be emulated by commons-rng. However, there is no
>>> guarantee the
>>> current implementation is used by all JDKs.
>>>
>>
>> There is; the generator definition is part of the API.
>>
>>
> And APIs are subject to change, albeit not very likely with the OOTB
> implementation of java.util.Random. So, if commons-rng is going to
> provide
> a UniformRandomProvider that behaves like java.util.Random, we are
> accepting the maintenance of said UniformRandomProvider should the
> java.util.Random implementation ever change. Since, the likelihood
> of
> java.util.Random ever changing is remote, using an equivalent LCG
> based
> UniformRandomProvider is probably acceptable as well since the
> probably
> maintenance cost is minute.
If the implementation of "Random" changes, and the need is to produce
the same sequence (of 32-bits integers) as "Random", then using a
"fixed"
Commons RNG algo won't work since Commons RNG and JDK won't agree
either
for older or for newer Java versions.
If it is possible that the JDK API changes in that way, then that would
be a reason to keep "RandomSource.JDK".
But if the JDK API changes in such a way, it would also break existing
applications that rely on the definition of the RNG used in "Random".
I'd have supposed that the development policy of the JDK would not
allow it.
> With that said, I started thinking a bridge to go between the two
> engines,
> UniformRandomProvider and java.util.Random, might be beneficial. For
> third
> parties that have implemented java.util.Random subclasses, it would
> be nice
> to provide the means to easily adapt their Random implementation to a
> UniformRandomProvider so it can be used in commons-rng related code.
Like method "asUniformRandomProvider" in
"o.a.c.math4.random.RandomUtils"
("master" branch)?
> Conversely, for third parties that use java.util.Random instances, it
> would
> be nice to easily adapt a UniformRandomProvider to a Random so the
> commons-rng generators could be used.
That would be possible (but the bridge must be from "RandomSource",
not "UniformRandomProvider"): see class
"o.a.c.math4.random.RngAdaptor".
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] Scope of "Commons RNG"
Posted by Brent Worden <br...@gmail.com>.
On Mon, Sep 26, 2016 at 6:21 PM, Gilles <gi...@harfang.homelinux.org>
wrote:
> On Mon, 26 Sep 2016 16:10:12 -0500, Brent Worden wrote:
>
>> I would keep the JDK source. My reasoning being:
>>
>> 1. Users that want to use java.util.Random would not be able to use some
>> or
>> all of the RNG Utils code as the later will probably relay on RandomSource
>> instances.
>>
>
> I don't understand the above.
> Could you provide an example of what should be, but won't
> be possible?
>
> I misspoke when I stated RandomSource. The RNG Utils code will probably
rely on UniformRandomProvider as its engine for random numbers. So, if I
wanted to use java.util.Random as the engine I was thinking to use the JDK
random source to create the equivalent UniformRandomProvider. I believe
what you are suggesting is if I wanted OOTB java.util.Random behavior I
would create the equivalent LCG based UniformRandomProvider (once said
functionality is available in commons-rng). I guess that is acceptable if
such a UniformRandomProvider creation is in the form of a convenience,
factory method so I am not required to know the correct LCG parameters to
use.
2. With LCGs the current Random implementation provided by Oracle could
>> possibly be emulated by commons-rng. However, there is no guarantee the
>> current implementation is used by all JDKs.
>>
>
> There is; the generator definition is part of the API.
>
>
And APIs are subject to change, albeit not very likely with the OOTB
implementation of java.util.Random. So, if commons-rng is going to provide
a UniformRandomProvider that behaves like java.util.Random, we are
accepting the maintenance of said UniformRandomProvider should the
java.util.Random implementation ever change. Since, the likelihood of
java.util.Random ever changing is remote, using an equivalent LCG based
UniformRandomProvider is probably acceptable as well since the probably
maintenance cost is minute.
With that said, I started thinking a bridge to go between the two engines,
UniformRandomProvider and java.util.Random, might be beneficial. For third
parties that have implemented java.util.Random subclasses, it would be nice
to provide the means to easily adapt their Random implementation to a
UniformRandomProvider so it can be used in commons-rng related code.
Conversely, for third parties that use java.util.Random instances, it would
be nice to easily adapt a UniformRandomProvider to a Random so the
commons-rng generators could be used.
Re: [RNG] Scope of "Commons RNG"
Posted by Gilles <gi...@harfang.homelinux.org>.
On Mon, 26 Sep 2016 16:10:12 -0500, Brent Worden wrote:
> I would keep the JDK source. My reasoning being:
>
> 1. Users that want to use java.util.Random would not be able to use
> some or
> all of the RNG Utils code as the later will probably relay on
> RandomSource
> instances.
I don't understand the above.
Could you provide an example of what should be, but won't
be possible?
> 2. With LCGs the current Random implementation provided by Oracle
> could
> possibly be emulated by commons-rng. However, there is no guarantee
> the
> current implementation is used by all JDKs.
There is; the generator definition is part of the API.
> Also, there a no guarantee the
> Oracle implement doesn't change in future versions of their JDK
I think there is for the same reason as above.
> and change
> to something that can not be emulated by commons-rng.
"RandomSource.JDK" does _not_ emulate "java.util.Random".
The only guarantee is that both provide the same sequences of
32-bits integers.
I.e. no such guarantee for any of the other "nextXxx" methods!
[See the docs.]
Regards,
Gilles
> So, to give users more flexibility in choosing a RandomSource and to
> be
> resilient to Random change, I feel the JDK source is beneficial.
>
> Brent
>
> On Mon, Sep 26, 2016 at 11:33 AM, Gilles
> <gi...@harfang.homelinux.org>
> wrote:
>
>> Hi.
>>
>> Reviving this thread following a new feature request:
>> https://issues.apache.org/jira/browse/RNG-19
>>
>> IMHO, the request departs from the initial goal (and, hence
>> the design "requirements" on which the current code is based).
>>
>> As I suggested previously on this list, I'm going to request
>> a new "git" repository for implementing utilities based on
>> random generators.
>>
>> First candidates are:
>> * Non-uniform deviates (i.e. the samplers now defined in
>> Commons Math's "o.a.c.math4.distribution" package),
>> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
>> * Data generation (e.g. random strings, currently defined in
>> Commons Math's "o.a.c.m.random.RandomUtils"),
>> * Syntactic sugar (e.g. strongly-type factory methods, as
>> suggested by Emmanuel during the RC1 vote),
>> * Bridge/wrappers (as suggested by Emmanuel in RNG-19, on JIRA).
>>
>> Thus, "RNG Utils" would have a much less tightened scope, allowing
>> for experimenting with user-requested codes.[1][2]
>>
>> Independently, I'm also wondering about removing the "JDK" element
>> from the "o.a.c.rng.RandomSource" enum.
>> Rationale is that this RNG should not be used.[3]
>> Once the LCG family of generators is available[4], the algorithm
>> provided by the JDK can be emulated.[5]
>>
>> WDYT?
>>
>>
>> Regards,
>> Gilles
>>
>> [1] Thus avoiding any impact on the stability of "Commons RNG" as a
>> simple, no-dependency, repository of PRNG algorithms ported to
>> Java (and usable as such).
>> [2] I'd also suggest to copy/move to that new component the related
>> utilities currently defined in Commons Lang.
>> [3] Users that _want_ to use "java.util.Random" for some reason will
>> probably be better off using it directly.
>> [4] https://issues.apache.org/jira/browse/RNG-16
>> [5] To be confirmed by a unit test...
>>
>>
>> On Wed, 21 Sep 2016 17:27:35 +0200, Emmanuel Bourg wrote:
>>
>>> Le 21/09/2016 � 14:46, Gilles a �crit :
>>>
>>> If we want "Commons RNG" to be a repository of all
>>>> generators that exist out there, irrespective of their
>>>> known weaknesses, it's fine; but we should be careful to
>>>> not let casual users just pick one of the implementations
>>>> on the premise that the library focuses on high quality
>>>> generators.
>>>>
>>>
>>> I think it's fine to have weaker implementations as long as they
>>> are
>>> properly documented with the necessary warnings. There aren't that
>>> many
>>> algorithms anyway, we'll quickly have the interesting ones.
>>>
>>>
>>> I have no issue with adding any new implementation,[4]
>>>> on the conditions that it comes with
>>>> 1. a unit test where the output (say, a few hundred
>>>> numbers) of "Commons RNG" is compared against a
>>>> "reference" implementation,[5]
>>>> 2. the outputs of the "RandomStressTester"[6] piping
>>>> from the "Dieharder" and "TU01/BigCrush" actual
>>>> stress test suites.[7]
>>>>
>>>
>>> Sounds fair
>>>
>>>
>>> [1] Emmanuel, if you don't mind, we'd thus set the JIRA
>>>> issue "type" to "wish" rather than "improvement".
>>>>
>>>
>>> As you want, that doesn't make a big difference. It could even
>>> qualify
>>> for the "New Feature" type.
>>>
>>> [2] https://xkcd.com/221/
>>>>
>>>
>>> Now I'm tempted to implement a XKCDRandomGenerator just for fun :)
>>>
>>> [3] Up to now, I had assumed that no known-to-be-bad
>>>> generators would be part of "Commons RNG" (except
>>>> "JDK", for reference purposes).
>>>>
>>>
>>> Note that as time goes some generators will be supplanted by better
>>> ones, so Commons RNG will inevitably contain implementations weaker
>>> than
>>> the then current state of the art.
>>>
>>> [4] It is not a problem to wait another couple of weeks
>>>> for the additional code, before releasing 1.0.
>>>>
>>>
>>> Ok, I can try implementing LCGs then.
>>>
>>> Emmanuel Bourg
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RNG] Scope of "Commons RNG"
Posted by Brent Worden <br...@gmail.com>.
I would keep the JDK source. My reasoning being:
1. Users that want to use java.util.Random would not be able to use some or
all of the RNG Utils code as the later will probably relay on RandomSource
instances.
2. With LCGs the current Random implementation provided by Oracle could
possibly be emulated by commons-rng. However, there is no guarantee the
current implementation is used by all JDKs. Also, there a no guarantee the
Oracle implement doesn't change in future versions of their JDK and change
to something that can not be emulated by commons-rng.
So, to give users more flexibility in choosing a RandomSource and to be
resilient to Random change, I feel the JDK source is beneficial.
Brent
On Mon, Sep 26, 2016 at 11:33 AM, Gilles <gi...@harfang.homelinux.org>
wrote:
> Hi.
>
> Reviving this thread following a new feature request:
> https://issues.apache.org/jira/browse/RNG-19
>
> IMHO, the request departs from the initial goal (and, hence
> the design "requirements" on which the current code is based).
>
> As I suggested previously on this list, I'm going to request
> a new "git" repository for implementing utilities based on
> random generators.
>
> First candidates are:
> * Non-uniform deviates (i.e. the samplers now defined in
> Commons Math's "o.a.c.math4.distribution" package),
> * Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
> * Data generation (e.g. random strings, currently defined in
> Commons Math's "o.a.c.m.random.RandomUtils"),
> * Syntactic sugar (e.g. strongly-type factory methods, as
> suggested by Emmanuel during the RC1 vote),
> * Bridge/wrappers (as suggested by Emmanuel in RNG-19, on JIRA).
>
> Thus, "RNG Utils" would have a much less tightened scope, allowing
> for experimenting with user-requested codes.[1][2]
>
> Independently, I'm also wondering about removing the "JDK" element
> from the "o.a.c.rng.RandomSource" enum.
> Rationale is that this RNG should not be used.[3]
> Once the LCG family of generators is available[4], the algorithm
> provided by the JDK can be emulated.[5]
>
> WDYT?
>
>
> Regards,
> Gilles
>
> [1] Thus avoiding any impact on the stability of "Commons RNG" as a
> simple, no-dependency, repository of PRNG algorithms ported to
> Java (and usable as such).
> [2] I'd also suggest to copy/move to that new component the related
> utilities currently defined in Commons Lang.
> [3] Users that _want_ to use "java.util.Random" for some reason will
> probably be better off using it directly.
> [4] https://issues.apache.org/jira/browse/RNG-16
> [5] To be confirmed by a unit test...
>
>
> On Wed, 21 Sep 2016 17:27:35 +0200, Emmanuel Bourg wrote:
>
>> Le 21/09/2016 à 14:46, Gilles a écrit :
>>
>> If we want "Commons RNG" to be a repository of all
>>> generators that exist out there, irrespective of their
>>> known weaknesses, it's fine; but we should be careful to
>>> not let casual users just pick one of the implementations
>>> on the premise that the library focuses on high quality
>>> generators.
>>>
>>
>> I think it's fine to have weaker implementations as long as they are
>> properly documented with the necessary warnings. There aren't that many
>> algorithms anyway, we'll quickly have the interesting ones.
>>
>>
>> I have no issue with adding any new implementation,[4]
>>> on the conditions that it comes with
>>> 1. a unit test where the output (say, a few hundred
>>> numbers) of "Commons RNG" is compared against a
>>> "reference" implementation,[5]
>>> 2. the outputs of the "RandomStressTester"[6] piping
>>> from the "Dieharder" and "TU01/BigCrush" actual
>>> stress test suites.[7]
>>>
>>
>> Sounds fair
>>
>>
>> [1] Emmanuel, if you don't mind, we'd thus set the JIRA
>>> issue "type" to "wish" rather than "improvement".
>>>
>>
>> As you want, that doesn't make a big difference. It could even qualify
>> for the "New Feature" type.
>>
>> [2] https://xkcd.com/221/
>>>
>>
>> Now I'm tempted to implement a XKCDRandomGenerator just for fun :)
>>
>> [3] Up to now, I had assumed that no known-to-be-bad
>>> generators would be part of "Commons RNG" (except
>>> "JDK", for reference purposes).
>>>
>>
>> Note that as time goes some generators will be supplanted by better
>> ones, so Commons RNG will inevitably contain implementations weaker than
>> the then current state of the art.
>>
>> [4] It is not a problem to wait another couple of weeks
>>> for the additional code, before releasing 1.0.
>>>
>>
>> Ok, I can try implementing LCGs then.
>>
>> 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: [RNG] Scope of "Commons RNG"
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
Reviving this thread following a new feature request:
https://issues.apache.org/jira/browse/RNG-19
IMHO, the request departs from the initial goal (and, hence
the design "requirements" on which the current code is based).
As I suggested previously on this list, I'm going to request
a new "git" repository for implementing utilities based on
random generators.
First candidates are:
* Non-uniform deviates (i.e. the samplers now defined in
Commons Math's "o.a.c.math4.distribution" package),
* Shuffling algorithm (cf. Commons Math's "o.a.c.m.MathArrays"),
* Data generation (e.g. random strings, currently defined in
Commons Math's "o.a.c.m.random.RandomUtils"),
* Syntactic sugar (e.g. strongly-type factory methods, as
suggested by Emmanuel during the RC1 vote),
* Bridge/wrappers (as suggested by Emmanuel in RNG-19, on JIRA).
Thus, "RNG Utils" would have a much less tightened scope, allowing
for experimenting with user-requested codes.[1][2]
Independently, I'm also wondering about removing the "JDK" element
from the "o.a.c.rng.RandomSource" enum.
Rationale is that this RNG should not be used.[3]
Once the LCG family of generators is available[4], the algorithm
provided by the JDK can be emulated.[5]
WDYT?
Regards,
Gilles
[1] Thus avoiding any impact on the stability of "Commons RNG" as a
simple, no-dependency, repository of PRNG algorithms ported to
Java (and usable as such).
[2] I'd also suggest to copy/move to that new component the related
utilities currently defined in Commons Lang.
[3] Users that _want_ to use "java.util.Random" for some reason will
probably be better off using it directly.
[4] https://issues.apache.org/jira/browse/RNG-16
[5] To be confirmed by a unit test...
On Wed, 21 Sep 2016 17:27:35 +0200, Emmanuel Bourg wrote:
> Le 21/09/2016 � 14:46, Gilles a �crit :
>
>> If we want "Commons RNG" to be a repository of all
>> generators that exist out there, irrespective of their
>> known weaknesses, it's fine; but we should be careful to
>> not let casual users just pick one of the implementations
>> on the premise that the library focuses on high quality
>> generators.
>
> I think it's fine to have weaker implementations as long as they are
> properly documented with the necessary warnings. There aren't that
> many
> algorithms anyway, we'll quickly have the interesting ones.
>
>
>> I have no issue with adding any new implementation,[4]
>> on the conditions that it comes with
>> 1. a unit test where the output (say, a few hundred
>> numbers) of "Commons RNG" is compared against a
>> "reference" implementation,[5]
>> 2. the outputs of the "RandomStressTester"[6] piping
>> from the "Dieharder" and "TU01/BigCrush" actual
>> stress test suites.[7]
>
> Sounds fair
>
>
>> [1] Emmanuel, if you don't mind, we'd thus set the JIRA
>> issue "type" to "wish" rather than "improvement".
>
> As you want, that doesn't make a big difference. It could even
> qualify
> for the "New Feature" type.
>
>> [2] https://xkcd.com/221/
>
> Now I'm tempted to implement a XKCDRandomGenerator just for fun :)
>
>> [3] Up to now, I had assumed that no known-to-be-bad
>> generators would be part of "Commons RNG" (except
>> "JDK", for reference purposes).
>
> Note that as time goes some generators will be supplanted by better
> ones, so Commons RNG will inevitably contain implementations weaker
> than
> the then current state of the art.
>
>> [4] It is not a problem to wait another couple of weeks
>> for the additional code, before releasing 1.0.
>
> Ok, I can try implementing LCGs then.
>
> 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: [RNG] Scope of "Commons RNG"
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 21/09/2016 � 14:46, Gilles a �crit :
> If we want "Commons RNG" to be a repository of all
> generators that exist out there, irrespective of their
> known weaknesses, it's fine; but we should be careful to
> not let casual users just pick one of the implementations
> on the premise that the library focuses on high quality
> generators.
I think it's fine to have weaker implementations as long as they are
properly documented with the necessary warnings. There aren't that many
algorithms anyway, we'll quickly have the interesting ones.
> I have no issue with adding any new implementation,[4]
> on the conditions that it comes with
> 1. a unit test where the output (say, a few hundred
> numbers) of "Commons RNG" is compared against a
> "reference" implementation,[5]
> 2. the outputs of the "RandomStressTester"[6] piping
> from the "Dieharder" and "TU01/BigCrush" actual
> stress test suites.[7]
Sounds fair
> [1] Emmanuel, if you don't mind, we'd thus set the JIRA
> issue "type" to "wish" rather than "improvement".
As you want, that doesn't make a big difference. It could even qualify
for the "New Feature" type.
> [2] https://xkcd.com/221/
Now I'm tempted to implement a XKCDRandomGenerator just for fun :)
> [3] Up to now, I had assumed that no known-to-be-bad
> generators would be part of "Commons RNG" (except
> "JDK", for reference purposes).
Note that as time goes some generators will be supplanted by better
ones, so Commons RNG will inevitably contain implementations weaker than
the then current state of the art.
> [4] It is not a problem to wait another couple of weeks
> for the additional code, before releasing 1.0.
Ok, I can try implementing LCGs then.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org