Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Wed, 7 May 2003 09:55:12 -0400 (EDT)
From: Henri Yandell <bayard@generationjava.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [lang] Support reseeding the RandomUtils random number generator
In-Reply-To: <3EB8991B.7000006@steitz.com>
Message-ID: <Pine.LNX.4.33.0305070939140.3482-100000@umbongo.flamefew.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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