bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Bug: Race theory, dice seed


From: Jim Segrave
Subject: Re: [Bug-gnubg] Bug: Race theory, dice seed
Date: Wed, 1 Oct 2003 13:39:27 +0200
User-agent: Mutt/1.2.5.1i

On Wed 01 Oct 2003 (08:28 +0100), Jon Kinsey wrote:
> At 07:39 01/10/2003, Joern Thyssen wrote:
> >On Tue, Sep 30, 2003 at 08:50:49PM +0200, Holger wrote
> > > At 15:02 30.09.2003, Joern Thyssen wrote:
> > > >On Tue, Sep 30, 2003 at 10:47:47AM +0000, Joern Thyssen wrote
> > > >> On Mon, Sep 29, 2003 at 09:46:13PM -0400, Christopher D. Yep wrote
> > > >> >
> > > >> > What is probably happening is that invoking the race theory window
> > > >causes
> > > >> > gnubg to set the dice seed to some given value.
> > > >>
> > > >> Yes, the one sided rollout sets the dice seed.
> > > >
> > > >The one sided rollout uses the Mersenne Twister RNG, so it only affects
> > > >those who use that.
> > > >
> > > >You'll observe the same kind of problem if you do a rollout with the
> > > >same RNG as you use for playing.
> > >
> > > Would it be possible to use a second instance of the RNG for other things
> > > then play so they don't disturb each other? (I mean, does the RNG code
> > > support this?)
> >
> >gnubg supports a number of RNGs. I guess some of them support multiple
> >instances, but others don't (e.g., BSD, ansi, and others).
> 
> It should be quite easy to add another Mersenne Twister RNG, which could be 
> used in all the non-playing areas.
> If that is the only RNG the roll-out/theory code needs.

It is quite strraightforward to have multiple copies of the initernal
state of the MT RNG. I would suggest that rather than add the
complexity of saving/restoring state on all paths through every code
block which uses the MT RNG, that we arrange that the various callers -
play, theory, and rollout are indicated so that the RNG can choose
which static structure it uses. This could be done by adding an
argument in all the appropriate places where the RNG is
accessed/affected:

PrintRNGSeed()
InitRNGSeed()
InitRNG()
RollDice()
and the calls to genrand/sgenrand in osr.c can be then replaced with
calls to InitRNGSeed and RollDice.
affected files:

database.c       - call RollDice with 'rollout' indicator
dice.c           - this is where most of the RNG interface takes place
gnubg.c          - initialises the 'play' and 'rollout' RNGs
                 - calls RollDice during training - use 'play'?
                 - CommandDiceRolls - use 'play' in RollDice calls
gtkboard.c       - use 'play' in RollDice calls
gtkprefs.c       - use 'play' in RollDice calls
gtkoptions.c     - option for setting the 'play' RNG seed 
lib/mt19937int.c - to add the various structs and modify the code to
                   use the selected struct
osr.c            - change to use InitRNGSeed and RollDice, call with
                   'theory' flag
play.c           - use 'play' in RollDice calls
rollout.c        - to set the 'rollout' seed and call RollDice with
                   the 'rollout' flag
set.c            - to set the 'play' seed
show.c           - to show the 'play' seed

Looking at the other RNGs, most could be modified to support multiple
parallel sequences, but the question is whether it's worth
doing. Saying that the training, rollout and osr functions will only
use Mersenne Twister, while leaving the play rng fully selectable
seems to me not to be any real loss of functionality.

-- 
Jim Segrave           address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]