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

[Holger]

At 13:39 01.10.2003, Jim Segrave wrote:
> 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
> > > > 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:

Does the RNG have to be static? Well, for play it could just be left how it 
is right now. All other functions could instantiate their own, e.g. on a 
start of a rollout. Or would this be too much overhead?

> Looking at the other RNGs, most could be modified to support multiple
> parallel sequences, but the question is whether it's worth

I was assuming we'd only use MT for everything else then play.

> 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.

I agree.

Regards,

        Holger