commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [lang] Support reseeding the RandomUtils random number generator
Date Wed, 07 May 2003 15:00:46 GMT
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 

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
>>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)?
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message