commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [RNG] Scope of "Commons RNG"
Date Wed, 28 Sep 2016 12:59:40 GMT
On Tue, 27 Sep 2016 20:07:19 -0500, Brent Worden wrote:
> On Mon, Sep 26, 2016 at 11:36 PM, Gilles 
> <>
> 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

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]


[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:
For additional commands, e-mail:

View raw message