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...@steitz.com> on 2003/05/07 07:26:51 UTC
[lang] Support reseeding the RandomUtils random number generator
I can see two ways to do this:
a) Leave the methods static,add a static field holding a
java.math.Random, which can be reseeded. "Scope" of seeding becomes
jvm/classloader.
b) Add the Random as an instance variable and change the methods to be
instance methods.
Pros of a): least change from current implementation, guarantees
"expected" random sequence behavior whether or not user ever reseeds.
Cons of a): usual objections to statics
Pros of b): user has full control of his/her instance, no statics
Cons of b): if user creates a new instance each time, behavior will be
similar to using new Random() each time, which does not generate a good
random sequence. To get a good sequence, user needs to create an
instance and use that instance repeatedly.
I have a patch that does a). Should I submit this or is b) a better
approach -- or is there another approach that is better than either a)
or b)?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] Support reseeding the RandomUtils random number generator
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 7 May 2003, Phil Steitz wrote:
> Henri Yandell wrote:
>
> > We would optionally add RandomUtils.nextInt(min, max) which would call on
> > through to RandomUtils.nextInt(JVM_RANDOM, min, max) as this would work as
> > the user would expect.
> >
> > So the static instance would not be reseedable, as with the JVM it would
> > effectively be immutable, but anyone who wants to use their own Random
> > instance can quite happily use the methods in RandomUtils in the
> > time-honoured XxxUtils.doThing(Xxx, others) way.
> >
> > How does that sound? It fixes the 'broken-ness' of RandomUtils' XxxUtils
> > contract [we need to document the XxxUtils contract somewhere] and gives
> > you a platform to start enhancing Random's methods in. You just don't get
> > the ability to change the JVM_RANDOM's seed and have to carry your own new
> > Random().
>
> Yes, this sounds like a good way to handle seeding which will be 100%
> backward compatable and will allow users to engage in just as much
> fiddling as they wish to. They will essentially have 3 choices: 1)
> current semantics -- behavior like math.Random(); 2) use their own
> Random; 3) manipulate the "JVM" Random.
>
> Here, if I understand correctly, is the sequence of enhancements to get
> us there:
>
> 0. add the simple "completeness" extensions mentioned above (maybe not
> the "sampling objects", since this may be better off somewhere else)
> 1. add the RandomUtils.doThing(Random,args) methods
> 2. add JVMRandom, exposed as RandomUtils.RANDOM
> 3. modify RandomUtils.doThing(args) to mean
> RandomUtils.doThing(RandomUtils.RANDOM,args).
>
> Did I get this right?
>
>
Ignoring the rude fact that I just went and did a bit of it :) JVMRandom
is in, and RandomUtils is modified to fit the new concept. All you now
need to do is supply a patch with your doThing's in.
Sorry if that's more work for you, I'll happily take a private email with
your old methods in and just integrate them if you'd prefer. Also
apologies for the slowness in this email compared to the cvs commit, my
LAN is dropping half the packets it seems.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] Support reseeding the RandomUtils random number generator
Posted by Phil Steitz <ph...@steitz.com>.
Henri Yandell wrote:
> Sorry for being sleepy on this Phil. I had forgotten that I wrote
> RandomUtils.
>
> Problem with reseeding as I see it, RandomUtils initial aim was just to
> make Math.random() more useful. ie) to simulate Math.RANDOM being public.
> So if it can be reseeded, but Math.RANDOM cannot, then we need to redefine
> it's reason for being.
OK, I get it now.
>
> Firstly, I think there's an important place for RandomUtils as is. ie)
> Linked to the same seed as Math.random() but providing the other methods.
> However there's also room for new improved Utils for Random objects such
> as your "b) add nextInt(min,max) (inclusive) and/or nextInt(IntRange r)".
>
Yes. I will submit patches for these, using the existing setup.
> Reseeding of the static instance is nice, but not a huge biggy.
> However....
>
> What I'm thinking is:
>
> RandomUtils, a series of static methods that take a Random object. So you
> would have:
>
> RandomUtils.nextInt(Random, min, max)
> RandomUtils.nextInt(Random)
> RandomUtils.chooseRandomly(Random, Collection, int, int) [ok. no clue what
> this would do]
Sounds reasonable, just need to make the contract clear.
>
> Then we would have JVMRandom, which extends Random. It would be an
> extension of java.util.Random which maps onto java.lang.Math.random(), in
> exactly the way that RandomUtils currently does. We would throw
> unsupported exceptions for setSeed(), nextGaussian() and nextBytes()
> [until we have implementations for the latter two] and make it available
> as RandomUtils.RANDOM or RandomUtils.JVM_RANDOM.
>
> We would optionally add RandomUtils.nextInt(min, max) which would call on
> through to RandomUtils.nextInt(JVM_RANDOM, min, max) as this would work as
> the user would expect.
>
> So the static instance would not be reseedable, as with the JVM it would
> effectively be immutable, but anyone who wants to use their own Random
> instance can quite happily use the methods in RandomUtils in the
> time-honoured XxxUtils.doThing(Xxx, others) way.
>
> How does that sound? It fixes the 'broken-ness' of RandomUtils' XxxUtils
> contract [we need to document the XxxUtils contract somewhere] and gives
> you a platform to start enhancing Random's methods in. You just don't get
> the ability to change the JVM_RANDOM's seed and have to carry your own new
> Random().
Yes, this sounds like a good way to handle seeding which will be 100%
backward compatable and will allow users to engage in just as much
fiddling as they wish to. They will essentially have 3 choices: 1)
current semantics -- behavior like math.Random(); 2) use their own
Random; 3) manipulate the "JVM" Random.
Here, if I understand correctly, is the sequence of enhancements to get
us there:
0. add the simple "completeness" extensions mentioned above (maybe not
the "sampling objects", since this may be better off somewhere else)
1. add the RandomUtils.doThing(Random,args) methods
2. add JVMRandom, exposed as RandomUtils.RANDOM
3. modify RandomUtils.doThing(args) to mean
RandomUtils.doThing(RandomUtils.RANDOM,args).
Did I get this right?
>
> Hen
>
> On Tue, 6 May 2003, Phil Steitz wrote:
>
>
>>I can see two ways to do this:
>>
>>a) Leave the methods static,add a static field holding a
>>java.math.Random, which can be reseeded. "Scope" of seeding becomes
>>jvm/classloader.
>>
>>b) Add the Random as an instance variable and change the methods to be
>>instance methods.
>>
>>Pros of a): least change from current implementation, guarantees
>>"expected" random sequence behavior whether or not user ever reseeds.
>>Cons of a): usual objections to statics
>>
>>Pros of b): user has full control of his/her instance, no statics
>>Cons of b): if user creates a new instance each time, behavior will be
>>similar to using new Random() each time, which does not generate a good
>> random sequence. To get a good sequence, user needs to create an
>>instance and use that instance repeatedly.
>>
>>I have a patch that does a). Should I submit this or is b) a better
>>approach -- or is there another approach that is better than either a)
>>or b)?
>>
>>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: [lang] Support reseeding the RandomUtils random number generator
Posted by Henri Yandell <ba...@generationjava.com>.
Sorry for being sleepy on this Phil. I had forgotten that I wrote
RandomUtils.
Problem with reseeding as I see it, RandomUtils initial aim was just to
make Math.random() more useful. ie) to simulate Math.RANDOM being public.
So if it can be reseeded, but Math.RANDOM cannot, then we need to redefine
it's reason for being.
Firstly, I think there's an important place for RandomUtils as is. ie)
Linked to the same seed as Math.random() but providing the other methods.
However there's also room for new improved Utils for Random objects such
as your "b) add nextInt(min,max) (inclusive) and/or nextInt(IntRange r)".
Reseeding of the static instance is nice, but not a huge biggy.
However....
What I'm thinking is:
RandomUtils, a series of static methods that take a Random object. So you
would have:
RandomUtils.nextInt(Random, min, max)
RandomUtils.nextInt(Random)
RandomUtils.chooseRandomly(Random, Collection, int, int) [ok. no clue what
this would do]
Then we would have JVMRandom, which extends Random. It would be an
extension of java.util.Random which maps onto java.lang.Math.random(), in
exactly the way that RandomUtils currently does. We would throw
unsupported exceptions for setSeed(), nextGaussian() and nextBytes()
[until we have implementations for the latter two] and make it available
as RandomUtils.RANDOM or RandomUtils.JVM_RANDOM.
We would optionally add RandomUtils.nextInt(min, max) which would call on
through to RandomUtils.nextInt(JVM_RANDOM, min, max) as this would work as
the user would expect.
So the static instance would not be reseedable, as with the JVM it would
effectively be immutable, but anyone who wants to use their own Random
instance can quite happily use the methods in RandomUtils in the
time-honoured XxxUtils.doThing(Xxx, others) way.
How does that sound? It fixes the 'broken-ness' of RandomUtils' XxxUtils
contract [we need to document the XxxUtils contract somewhere] and gives
you a platform to start enhancing Random's methods in. You just don't get
the ability to change the JVM_RANDOM's seed and have to carry your own new
Random().
Hen
On Tue, 6 May 2003, Phil Steitz wrote:
> I can see two ways to do this:
>
> a) Leave the methods static,add a static field holding a
> java.math.Random, which can be reseeded. "Scope" of seeding becomes
> jvm/classloader.
>
> b) Add the Random as an instance variable and change the methods to be
> instance methods.
>
> Pros of a): least change from current implementation, guarantees
> "expected" random sequence behavior whether or not user ever reseeds.
> Cons of a): usual objections to statics
>
> Pros of b): user has full control of his/her instance, no statics
> Cons of b): if user creates a new instance each time, behavior will be
> similar to using new Random() each time, which does not generate a good
> random sequence. To get a good sequence, user needs to create an
> instance and use that instance repeatedly.
>
> I have a patch that does a). Should I submit this or is b) a better
> approach -- or is there another approach that is better than either a)
> or b)?
>
> 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