[RNG] Scope of "Commons RNG"

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

Re: [lang] Shuffling arrays

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Brent Worden-2
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 <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Scope of "Commons RNG"

Brent Worden-2
In reply to this post by Gilles Sadowski
On Mon, Sep 26, 2016 at 11:36 PM, Gilles <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

garydgregory
In reply to this post by Brent Worden-2
+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 <[hidden email]>
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 <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Gilles Sadowski
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
> <[hidden email]>
> 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
>> <[hidden email]>
>> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>


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

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Emmanuel Bourg-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] Scope of "Commons RNG"

Gilles Sadowski
In reply to this post by Brent Worden-2
On Tue, 27 Sep 2016 20:07:19 -0500, Brent Worden wrote:

> On Mon, Sep 26, 2016 at 11:36 PM, Gilles
> <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

jochen-2
In reply to this post by Gilles Sadowski
On Wed, Sep 28, 2016 at 1:40 PM, Gilles <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
In reply to this post by Emmanuel Bourg-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

Gilles Sadowski
In reply to this post by jochen-2
On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:

> On Wed, Sep 28, 2016 at 1:40 PM, Gilles
> <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

garydgregory
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 <[hidden email]>
wrote:

> On Wed, 28 Sep 2016 15:55:34 +0200, Jochen Wiedmann wrote:
>
>> On Wed, Sep 28, 2016 at 1:40 PM, Gilles <[hidden email]>
>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Shuffling arrays

jochen-2
In reply to this post by Gilles Sadowski
On Wed, Sep 28, 2016 at 4:55 PM, Gilles <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Emmanuel Bourg-3
In reply to this post by Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Artem Barger
In reply to this post by Emmanuel Bourg-3
​Hi,



On Thu, Sep 29, 2016 at 1:06 PM, Emmanuel Bourg <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Stian Soiland-Reyes
In reply to this post by Gilles Sadowski
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
Stian Soiland-Reyes
http://orcid.org/0000-0001-9842-9718

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

Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Artem Barger
On Thu, Sep 29, 2016 at 1:48 PM, Stian Soiland-Reyes <[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

Re: [RNG] modules vs projects

Gilles Sadowski
In reply to this post by Artem Barger
On Thu, 29 Sep 2016 13:40:08 +0300, Artem Barger wrote:
> ​Hi,


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

>
> On Thu, Sep 29, 2016 at 1:06 PM, Emmanuel Bourg <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

1234