commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [lang] Shuffling arrays (was: [RNG] Scope of "Commons RNG")
Date Tue, 27 Sep 2016 11:22:21 GMT

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 

> 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 
The factory method "asUniformRandomProvider" creates an instance that
redirects all the interface methods to their counterpart in "Random" 
they exist): sequence of any type is the same, whether the Random 
is wrapped or not.  "RngAdapter" however creates a "Random" instance 
only 32-bits integers sequences are preserved.

Moreover, the default RNG should be a good one, i.e. not 

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 
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.


> Emmanuel Bourg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message