Re: [Bug-gnubg] Minor rollout setting patches

[Jim Segrave]

On Mon 18 Nov 2002 (09:12 +0000), Joern Thyssen wrote:
> On Sat, Nov 16, 2002 at 09:20:41PM +0100, Jim Segrave wrote
> > On Sun 17 Nov 2002 (08:07 +1300), Joseph Heled wrote:
> > > 
> > > Why not give Jim write permission in the CVS so he can put his changes 
> > > directly?
> > > 
> > > -Joseph
> > 
> > I've never minded if someone else had a look at what I've done before
> > commiting it, as my knowledge of large parts of gnubg (and backgammon
> > in general) is still pretty limited.
> 
> So far it's been very good code :-)

Thanks. I can return the compliment to the other developers by
pointing out that I haven't had much difficulty finding my way around
the code (or stealing chunks of it so I didn't have to learn gtk
myself). 

> I suggest you open an account on savannah.gnu.org. I'll give to write
> access to CVS if you send me your user ID.

OK - I've created an account with username jsegrave and put my ssh
keys up (though I'll have to wait a while for them to be installed,
then see if they work).

I've got another update, but I'd like opinions from others before
deciding to commit it:

I've changed the code in rollout.c:

If you don't select rotate-rolls, all rolls are random (as it is now):

If you do select rotate-rolls, regardless of the number of trials you
have set, it will generate the first 4 rolls of any game such that:

Every 30/36 games, every first roll will appear once.

Every 1080/1296 games, every pair of roll 1, roll 2 will appear once

Every 38880/46656 games, every triplet of roll 1, roll 2, roll 3 will appear
once. 

And every 1399680/1679616, every quad of roll 1, roll 2, roll 3, roll 4
will appear once.

The benefit is that if you start a rollout with rotate-rolls and
terminate it before you reach a multiple of one of the above games,
the results will not be skewed by having a preponderence of 11,
12, 13 etc. first rolls, as the rolls appear in a  psuedo-random, but
constrained order. But everytime you do hit one of those multiples,
you will have done an exhaustive coverage of the first n rolls.

There are two possible ways that the rolls will be randomised:

1) complete - this happens on the first rollout after starting gnubg
   and can be forced at any time by toggling rotate-rolls off and on.

2) partial - there is an array of 46656 sets of values for rolls 2..4
   which is setup only in a complete randomisation. But there are 1296
   different ways to use that array while meeting the constraints, and
   one of these is selected whenever a rollout command is initiated.

The psuedo-random ordering is done using random() and the generator is
seeded from the current rolloutcontext nSeed when doing a complete
randomisaton. To produce absolutely identical rollouts with different
runs of gnubg (which I was doing for testing purposes), you would need to:

1) set the rng seed to the same value.  

2) toggle rotate-rolls on and off to force a complete randomisation
   (my patches will make this work in the GUI without having to click
   on OK - simply turning the check box off and back on is sufficient)

The down side of all this is the cost of an array of about 46656
shorts and the cpu time to set up the sequences. The time is not
noticable for a complete setup and is insignificant for partial
randomising.

-- 
Jim Segrave           address@hidden