On Tue, 27 Sep 2016 20:07:19 -0500, Brent Worden wrote:
On Mon, Sep 26, 2016 at 11:36 PM, Gilles
<gil...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
