bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Rollout bugs (j.s.d. options)


From: Jim Segrave
Subject: Re: [Bug-gnubg] Rollout bugs (j.s.d. options)
Date: Thu, 31 Jul 2003 16:13:55 +0200
User-agent: Mutt/1.2.5.1i

On Thu 31 Jul 2003 (08:39 -0400), Christopher D. Yep wrote:
> At 08:49 AM 7/31/2003 +0200, Jim Segrave wrote:
> >On Thu 31 Jul 2003 (00:36 -0400), Christopher D. Yep wrote:


> > > Set minimum trials to 36 and "No of j.s.d.s from best move to .001"
> > >
> > > Then set-up the position, press CTRL-H to get a hint window, and select 
> > 8/5
> > > 6/5 and 24/23 13/10 to rollout.  gnubg should then rollout each 36
> > > times.  Actually gnubg rolls out each 37 times (bug #1).
> > >
> > > Bug #1: If I set minimum trials to N, the actual minimum trials is N+1.
> >
> >Just to check - do you know when your copy of gnubg was built? I don't
> >get this error with the current version.
> 
> Windows version 0.14-devel 1.1227 030727 (build Jul 27 2003).  I can 
> download a more recent build, but I didn't see any mention of a bug fix 
> related to this bug in the ChangeLog since 1.1227.
> 
> Also I can visually see that it's doing 37 trials (I watched each number 
> change).  For some of the testing I changed the minimum number of trials to 
> 2 so that it would run even faster (in the latter case it would run 3 
> trials of each move).
> 
> Here's a sample of the output (copied from the hint window), so it appears 
> to be more than just a cosmetic bug in the progress window:
> 
>      1. Rollout          8/5 6/5                      Eq.:  +0.142
>          53.9%  18.2%   0.4% -  46.1%  11.7%   0.4% CL  +0.142
>        [  1.2%   1.0%   0.2% -   1.2%   1.0%   0.1% CL   0.033]
>          Full cubeless rollout (trunc. at one-sided bearoff) with var.redn.
>          37 games, Mersenne Twister dice gen. with seed 1174625920 and 
> quasi-random dice
>          Play: 0-ply cubeful
>          Cube: 0-ply cubeful
>      2. Rollout          24/23 13/10                  Eq.:  -0.068 ( -0.210)
>          47.5%  11.4%   0.4% -  52.5%  13.2%   0.5% CL  -0.068
>        [  1.3%   1.1%   0.7% -   1.3%   1.0%   0.1% CL   0.035]
>          Full cubeless rollout (trunc. at one-sided bearoff) with var.redn.
>          37 games, Mersenne Twister dice gen. with seed 1174625920 and 
> quasi-random dice
>          Play: 0-ply cubeful
>          Cube: 0-ply cubeful

I really can't reporduce this and nothing that could affect it has
been changed since well before 27 July. Very odd

...

> >Current version is a bit better, one of the two options works
> >correctly, the other does not. I'll fix this sometime today.
> 
> Actually I was mistaken before.
> 
> If I check only the first box ("stop rollout when one move appears to be 
> the best"), gnubg will do 1 trial.  (This is definitely a bug.)

It's fixed now
 
> If I check only the second box ("stop rollout of move when best move j.s.d. 
> appears better"), gnubg will rollout as many trials as is specified in the 
> Trials box at the very top of the Rollout General Settings window (i.e. 
> this is different than the "minimum trials" next to "stop rollout when one 
> move appears to be the best").  This seems like it might be a bug, although 
> it might be your intended behavior.

If you are only rolling out one move, then there's nothing to make a
joint standard deviation, so the settings for this are ignored. That
should have happend when the "one move appears to be best" box was
ticked, but owing to a bug, it didn't. Now it does and in single move
rollouts it will always do the full specified number of trials.

> > > Minor Bug #3: Even if I don't check any box in "Stop when result is
> > > accurate" or "stop rollouts of multiple moves based on j.s.d.", when I
> > > click "Ok" gnubg reports that "Rollouts can stop..." and "Rollouts may
> > > stop..." when these conditions are met.  (However gnubg correctly ignores
> > > these conditions in its rollouts, thus the above is just a "cosmetic" 
> > > bug.)
> >
> >As in bug 1, I saw earlier reports of this, but I can't reproduce this
> >on the current version (although I never conciously fixed it).
> 
> I'll see if it goes away on later versions.  If it doesn't go away, I can 
> give you more details on how to reproduce it in a few days or weeks.  This 
> is just a cosmetic bug anyway.

Nothing's been done to fix this either. I think that was a bug in the
very first release of this feature, but if it was there, it's been
gone a long time. Again I wonder about this. It's almost as if an
older version of rollout.c was used in the build.



-- 
Jim Segrave           address@hidden





reply via email to

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