Re: [Bug-gnubg] Cube decision rollout statistics

[Jim Segrave]

On Fri 18 Jul 2003 (08:13 +0000), Joern Thyssen wrote:
> On Fri, Jul 18, 2003 at 02:09:51AM +0200, Jim Segrave wrote
> 
> > I'm building an update now which addresses some cube rollout problems,
> > I'll look into the statistics output as well. In fact, while writing
> > this and looking, I have found and fixed the stats code. I still have
> > some work to do to use the new output routines, so it will be this
> > weekend when the fixes are commited. The fixes address the incorrect
> > display of equities in the rollout window (although the correct value
> > is shown in the annotation window when the rollout is complete). 
> 
> Which values are shown wrong? (for which settings)

Cubeless and cubeful equities in the rollout window for having doubled
when doing a rollout of a cube decision and displaying equity rather
than MWC.

The calls to calculate these are more or less like:

  mwc2eq (eq2mwc (aarMu[], aci[alt]), aci[0])

But the aci[0] wasn't being passed, instead aci[alt] was being passed,
so the calculation of mwc2eq was done with half the correct cube value.

While looking at the statistics, I found an interesting point:

Before my changes, gnubg rolled out cube decisions by calling 
BasicCubefulRollout and telling it to do both the no-double and double
decisions in one pass. The hit statistics are counted for centered
cube if there is a hit in the centered game (and not included in the
stats for the cube turned). I'm rolling the centered and cube turned
out in separate passes through BasicCubefulRollout and the hits are
counted in both passes, giving a discrepancy between the two. I don't
know which is the better report, for the moment, I've accepted the new
behaviour.

In fact, I have just committed the new stuff.

Outside of fixing cube rollout progress window values and the cube
statistics reports (they now match, except as noted above) the results
from a July 1 gnubg.

The new version also includes a new way of stopping either a rollout
of one particular move or a complete rollout, based on the joint
standard deviation of the equity differences. 

Users can elect to rollout out a minimum number of trials, after
which, at the end of each round of trials, the moves are ranked in
order of cubeful (or cubeless if it's not cubeful) equity and the
j.s.d. of the difference in equity between a given move/decision and
the best move/decision being rolled out. If the difference is more
than some user selected multiple of the j.s.d. of the difference, the
move/decision will not be rolled out any further. A second tick box
allows the user to tell the rollout to stop completely when one move
is move than a user selected number of j.s.d.s better than any other.

The code deals with some problematic behaviour as well:

Suppose you have 3 moves, A, B and C. You tell gnubg to rollout each
one at least 360 times, then to stop rolling out any move whose equity
is more than 1.96 j.s.d.s below the best of A, B and C. Let's say that
at 500 games, C drops out of consideration because it's now 2.0
j.s.d.s away from A, which is the best move. Then at trial 600 of A
and B, their equities have dropped such that C is now only 1.8 j.s.d.s
away. C (and for that matter any other candidates) will be rolled out
until it too has 600 games, then the rollout continues.

I've added another column to the Rollout Progress Window. The entry in
the top line of this column contains the relative ranking of the moves
and a one letter flag 'S' or 'R' to indicate if we have Stopped or are
still Rollingout that move. The second line is the number of j.s.d.s
that this move is from the best move found.

At the same time I've also ensured that changing the state of Cubeful
rollouts on the main page is reflected in all of the evaluations - if
you go from Cubeless to Cubeful, all evaluations become Cubeful, and
vice-versa.

There was a slight oversight in the 'set output digits' command - it
actually couldn't be reached, as it wasn't listed in acSetOutput[] in
gnubg, now fixed.

Comments welcome, bug reports less so :-)


-- 
Jim Segrave           address@hidden