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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org