Re: [Bug-gnubg] quasi-random dice for the Initial Position

[Jim Segrave]

On Mon 07 Jul 2003 (10:34 +0000), Joern Thyssen wrote:
> On Mon, Jul 07, 2003 at 11:45:19AM +0200, Jim Segrave wrote
> > On Mon 07 Jul 2003 (07:28 +0000), Joern Thyssen wrote:
> > > On Mon, Jul 07, 2003 at 08:50:39AM +0200, Jim Segrave wrote
> > > [snip]
> > > > 
> > > > The dice sequence doesn't know how man trials it will be asked for, it
> > > > simply generates sequences such that every 30/36 games you get all
> > > > possible 1st rolls, every 1080/1296 games get every possible first 2
> > > > rolls, every 38880/46656 games you get full sets of 3 rolls, etc.
> > > 
> > > Hmm, are you sure? 
> > 
> > I'm going by the comments and a skim of the code, so no, I'm not
> > sure. But, if the code works correctly for non-initial positions and
> > produces correct results for 1296 games, 46656 games, etc. then it
> > would be true that deleting those sequences which begin with a double
> > should preserve the correctness of 2nd rolls. I'm not vouching for the
> > underlying code (I haven't actually read it in detail to see if that's
> > what it does). But I do have a perl script for taking lists of rolls
> > and checking the distributions for the first 3 rolls - I think I'll
> > lift the code out of rollout.c and try running the output on my
> > script.
> 
> Aha, I may have found the bug:
> 
> nSkip is local to the "if ( fInitial && !iTurn )" part of RolloutDice.
> Shouldn't it be global inside RolloutDice and be used in the "else if (
> fRotate && iTurn )" part as well:

I was about to post the same finding and a very similar fix. The work
I'm doing on rollouts already required that nSkip get moved out to
file scope.

I extracted the code from rollout.c and made a test harness that only
generates the first n rolls (where n is 1 for < 1080/1296 games, 2 for
< 38880/46656, etc. and outputs them to stdout. I have a perl script
which checks that the first 30/36 games have all the initial opening
rolls and that each following block of 30/36 is the same. It does the
same for the first 1080/1296, checking for the correct representation
of the first two rolls, etc. I've tested your fix (and mine, which is 
effectively the same) up to 5 rolls deep and it's correct.

My original answer that it worked should have been true.

-- 
Jim Segrave           address@hidden