commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] Making PRNG pluggable in o.a.c.m.random classes
Date Wed, 11 May 2005 05:43:50 GMT
On 5/10/05, Brent Worden <brent@worden.org> wrote:
> > >1) Extract the interface from java.util.Random -- same names and
> > >contracts.  Call this interface RandomGenerator.  It will contain:
> > >
> > >setSeed(long seed)
> > >nextBytes(byte[] bytes)
> > >int nextInt()
> > >int nextInt(int n)
> > >long nextLong()
> > >boolean nextBoolean()
> > >double nextDouble()
> > >float nextFloat()
> > >double nextGaussian()
> > >
> 
> I would prefer to separate out these generation methods into different
> types.  IMO, the RandomGenerator interface should contain a sole generation
> method.  One of:
>   int next(int numberOfBits) // similar to the java.util.Random method
>   int next() // discrete uniform over [0, Integer.MAX_VALUE]
>   double next() // uniform over [0, 1)
> 
> The remaining methods I would implement as specialized random variable
> generators that use a RandomGenerator instance as an engine.
> 
> Brent Worden
> 

Here is what i am testing now.  I am happy to refactor before committing.   

First, I extracted the interface as described above, added a
constructor to RandomDataImpl taking a RandomGenerator and modified
the methods that use a Random instance to use a RandomGenerator
instead.  I implemented this, adding a JDKRandomGenerator that just
extends Random to implement the interface.  All current tests run and
this should be a backward compatible change.

Then I created an AbstractRandomGenerator with abstract methods seed
and nextDouble and default implementations of the other methods based
on nextDouble().  The value of this approach is that it provides a
generic way to replace java.util.Random, given a PRNG that can
generate uniform deviates.  The RngPack generators can then all be
easily plugged in by just delegating nextDouble() to their raw()
methods.

I suppose that I could remove the "derived methods" from the interface
and have the JDKRandomGenerator derive from the
AbstractRandomGenerator class and wrap, rather than extend Random. 
But then pluggability in RandomDataImpl would require inheritance and
it seemed simpler and more flexible to me to use an interface. 
Alternatively,  we could also define a base interface that is extended
by the Random-style interface, or multiple of these for the different
types you mention (including byte-generation, which we need).  I would
be fine with adding these if this is what you mean above.

An interesting question is which of the methods that you mention above
should be the "base" used in the abstract base class(es).  I think the
JDK is int-based, while RngPack appears to be uniform-based.  The most
flexible setup might be to implement abstract classes based on each of
the three.  Implementations are tricky, though.

Let me know what you think.  Unless there are objections, once I
complete testing and docs, I will commit things as described above
(probably not until this weekend).  As I said, I am happy to refactor.
 The only thing that I want to make sure of is that the changes are
backward compatible.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message