You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2005/05/08 07:31:55 UTC

[math] Making PRNG pluggable in o.a.c.m.random classes

Here is the plan that I proposed a while back.  Better ideas /
improvements welcome.  Also, can someone confirm that step 1 below is
OK from license/IP perspective?  - thx

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()

2) Add constructors to RandomDataImpl and ValueServer that take
RandomGenerator arguments and setGenerator(RandomGenerator) methods.
Leave the "secure" methods and SecureRandom members alone - the "secure"
PRNG is already pluggable.

3) Add sample code to the User Guide showing how to create an adaptor
for RngPack, or, alternatively, introduce a compile-time dependency on
RngPack and add the adaptor.

Phil

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


Re: [math] Making PRNG pluggable in o.a.c.m.random classes

Posted by Brent Worden <br...@worden.org>.
Adding a wrapper makes total sense.  That way, any RandomGenerator (ours or 
someone elses) implementation can be used where Random objects are required. 
Likewise, a RandomGenerator that wraps a Random would be a good addition. 
Then any Random extension can be used inside commons-math.  With those two 
wrappers we would have complete, bi-directional pluggability with the J2SE.

Brent


"Phil Steitz" <ph...@gmail.com> wrote in message 
news:8a81b4af05052214304d772efb@mail.gmail.com...
Thanks, Brent.
As I write up the docs, I am thinking about adding one more thing,
which I would apprecate feedback on.  I mentioned above that the
RandomGenerator / AbstractRandomGenerator provided a generic facility
for replacing java.util.random.  Recompilation is still required,
however, to use this.  I am thinking now that it might be useful to
add a class that *extends* java.util.Random to wrap a RandomGenerator
to make it possible to do this in a binary compatible way.  Does this
make sense?

Phil



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


Re: [math] Making PRNG pluggable in o.a.c.m.random classes

Posted by Phil Steitz <ph...@gmail.com>.
Thanks, Brent.
As I write up the docs, I am thinking about adding one more thing,
which I would apprecate feedback on.  I mentioned above that the
RandomGenerator / AbstractRandomGenerator provided a generic facility
for replacing java.util.random.  Recompilation is still required,
however, to use this.  I am thinking now that it might be useful to
add a class that *extends* java.util.Random to wrap a RandomGenerator
to make it possible to do this in a binary compatible way.  Does this
make sense?

Phil

On 5/21/05, Brent Worden <br...@worden.org> wrote:
> The implementation looks good an a lot less heftier than what I was
> anticipating.
> 
> Good work,
> 
> Brent Worden
> 
> > -----Original Message-----
> > From: Phil Steitz [mailto:phil.steitz@gmail.com]
> > Sent: Sunday, May 15, 2005 1:39 PM
> > To: Jakarta Commons Developers List
> > Subject: Re: [math] Making PRNG pluggable in o.a.c.m.random classes
> >
> > I committed the changes described above.  Feedback welcome.
> > I tested adapting and integration a RngPack generator.
> > Adaptor for Mersenne Twister looks like this (base adaptor
> > for all RngPack generators would be similar):
> >
> > /**
> >  * AbstractRandomGenerator based on RngPack RanMT generator.
> >  */
> > public class TestRngPackGenerator extends AbstractRandomGenerator {
> >
> >     private RanMT random = new RanMT();
> >
> >     public void setSeed(long seed) {
> >        random = new RanMT(seed);
> >     }
> >
> >     public double nextDouble() {
> >         return random.raw();
> >     }
> >
> >     public double nextGaussian() {
> >         return random.gaussian();
> >     }
> >
> >     public int nextInt(int n) {
> >         return random.choose(n);
> >     }
> >
> >     public boolean nextBoolean() {
> >         return random.coin();
> >     }
> > }
> >
> > I will update the user guide to include this and other
> > examples assuming all are OK with these changes.
> >
> > Phil
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

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


RE: [math] Making PRNG pluggable in o.a.c.m.random classes

Posted by Brent Worden <br...@worden.org>.
The implementation looks good an a lot less heftier than what I was
anticipating.

Good work,

Brent Worden  

> -----Original Message-----
> From: Phil Steitz [mailto:phil.steitz@gmail.com] 
> Sent: Sunday, May 15, 2005 1:39 PM
> To: Jakarta Commons Developers List
> Subject: Re: [math] Making PRNG pluggable in o.a.c.m.random classes
> 
> I committed the changes described above.  Feedback welcome.  
> I tested adapting and integration a RngPack generator.  
> Adaptor for Mersenne Twister looks like this (base adaptor 
> for all RngPack generators would be similar):
> 
> /**
>  * AbstractRandomGenerator based on RngPack RanMT generator.
>  */
> public class TestRngPackGenerator extends AbstractRandomGenerator {
>     
>     private RanMT random = new RanMT();
>     
>     public void setSeed(long seed) {
>        random = new RanMT(seed);
>     }
>     
>     public double nextDouble() {
>         return random.raw();
>     }
>     
>     public double nextGaussian() {
>         return random.gaussian();
>     }
>     
>     public int nextInt(int n) {
>         return random.choose(n);
>     }
>     
>     public boolean nextBoolean() {
>         return random.coin();
>     }
> }
> 
> I will update the user guide to include this and other 
> examples assuming all are OK with these changes.
> 
> Phil
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


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


Re: [math] Making PRNG pluggable in o.a.c.m.random classes

Posted by Phil Steitz <ph...@gmail.com>.
I committed the changes described above.  Feedback welcome.  I tested
adapting and integration a RngPack generator.  Adaptor for Mersenne
Twister looks like this (base adaptor for all RngPack generators would
be similar):

/**
 * AbstractRandomGenerator based on RngPack RanMT generator.
 */
public class TestRngPackGenerator extends AbstractRandomGenerator {
    
    private RanMT random = new RanMT();
    
    public void setSeed(long seed) {
       random = new RanMT(seed);
    }
    
    public double nextDouble() {
        return random.raw();
    }
    
    public double nextGaussian() {
        return random.gaussian();
    }
    
    public int nextInt(int n) {
        return random.choose(n);
    }
    
    public boolean nextBoolean() {
        return random.coin();
    }
}

I will update the user guide to include this and other examples
assuming all are OK with these changes.

Phil

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


Re: [math] Making PRNG pluggable in o.a.c.m.random classes

Posted by Phil Steitz <ph...@gmail.com>.
On 5/10/05, Brent Worden <br...@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


RE: [math] Making PRNG pluggable in o.a.c.m.random classes

Posted by Brent Worden <br...@worden.org>.
> >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


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


Re: [math] Making PRNG pluggable in o.a.c.m.random classes

Posted by Mark Diggory <md...@gmail.com>.
I think this would be a fine step towards plugability. I think you'll 
find something similar in Colt.

Phil Steitz wrote:

>Here is the plan that I proposed a while back.  Better ideas /
>improvements welcome.  Also, can someone confirm that step 1 below is
>OK from license/IP perspective?  - thx
>
>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()
>
>2) Add constructors to RandomDataImpl and ValueServer that take
>RandomGenerator arguments and setGenerator(RandomGenerator) methods.
>Leave the "secure" methods and SecureRandom members alone - the "secure"
>PRNG is already pluggable.
>
>3) Add sample code to the User Guide showing how to create an adaptor
>for RngPack, or, alternatively, introduce a compile-time dependency on
>RngPack and add the adaptor.
>
>Phil
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>


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