Re: [Bug-gnubg] Bug: Double/Beaver

[Christopher D. Yep]

At 01:46 PM 8/21/2003 +0000, Jørn Thyssen wrote:
> On Thu, Aug 21, 2003 at 09:05:54AM -0400, Christopher D. Yep wrote
>
> > Right, the cubeless equities reported don't seem to match up with the
> > win/gammon/backgammon figures reported.  E.g. 2-ply cubeless equity should
> > be .383 + .282 + .062 - (1 - .383) - .147 - .000 = -.037.

(Actually as a trivial aside, I meant to write -.038, the difference due to 
the fact that I'm using .3830, .2820, .0620, .1470, and .0000, when the 
actual values may differ in the 4th decimal place.)

> The cubeless equity is calculated with the current gammon price of 0
> (due to the jacoby rule). I better change that.

Thanks.  This will make it consistent with Analyse-Hint.

> >
> > Here's Analyse - Evaluate after I move a 2-cube over to the other side:
> >
> >         Win     W(g)    W(bg)   L(g)    L(bg)   Equity    Cubeful
> > static:  42.0%   34.2%    7.7%   12.8%    0.1%   +0.131    -0.066
> >  1 ply:  42.6%   29.0%    6.8%   11.2%    0.1%   +0.096    -0.083
> >  2 ply:  38.3%   28.6%    7.1%   14.9%    0.0%   -0.027    -0.107
> >
> > Ok, so now I match your reported numbers exactly (you wrote: "0.383 0.286
> > 0.071 0.149 0.000 -0.027 -0.107").  But that means that there's another 
> bug
> > as -0.107 is quite different from -0.236.
>
> No, I do expect a value around -0.1 since the value is being reported
> normed to 1. In the cube analysis the "no double" equity is reported
> normed to 1 and the "double, take" equity is reported normed to 2 (for
> money play -- for match play we use MWCs).
>
> The difference probably comes from "chequer play according to score".
> For the cube decision gnubg plays according to the undoubled cube, but
> for the evaluation after the double gnubgs plays according to the
> current cube (i.e., the 2-cube). This may cause gnubg to play
> differently at the intermediate plies leading to different gwc and
> equities[*].
>
> Jørn
>
> [*] This problem is due to the forward pruning we employ, and will
> hopefully be fixed in the future by Thomas Hauks implementation of the
> *-minimax algorithm.

Thanks, everything is clear now.  The -0.107 is normalized from a 2-cube to 
a 1-cube when I perform Analyse-Evaluate, i.e. it's about -0.214 in 
absolute equity.  This differs from the -0.236 solely due to checker play 
according to score (i.e. cube location in the case of a money game) as you 
note above.

Thus, I agree that gnubg is doing everything correctly here and that there 
is no bug with the -0.107 value.  As I think about it more, I like the way 
gnubg does it.

Btw, can you give me more information about how GNU makes cubeful checker 
plays?  If I have the "cubeful chequer evaluation" boxes checked, I'm 
guessing it means that every 0-ply evaluation, including every lookahead, 
is performed according to the cube location (and value, if a match).  So 
for example if at 6-ply a particular sequence of dice rolls involves the 
cube alternating back and forth across the board (redouble/take each turn), 
then for this particular sequence of dice rolls half the plies will be 
evaluated cubeful based on player0 owning the cube and half evaluated 
cubeful based on player1 owning the cube, correct?

For any position with a centered cube, the win/gammon/backgammon numbers 
reported with Analyse-Hint are obtained by assuming that gnubg does *not* 
double on the first roll, but with the cube being turned during the 
lookahead whenever gnubg thinks it's appropriate.  If I do a rollout on 
this position, there are two sets of numbers reported; the 
win/gammon/backgammon numbers reported by the double/take entry are 
obtained by assuming that gnubg doubles on the first roll and plays cubeful 
after that.  Correct?

For every N-ply evaluation and every rollout, if some of the nodes of the 
lookahead end in double/pass before N-plies are reached, for the purpose of 
the win/gammon/backgammon breakdown, gnubg uses the final 
win/gammon/backgammon estimate for these nodes rather than continuing all 
the way to N-ply, correct?

Finally, for an N-ply evaluation are all intermediate plies during 
lookahead always evaluated at 0-ply (this is what Jellyfish 3.5 and Snowie 
3.2 do for example)?  If so, gnubg can be marginally improved by using 
minimax as you note, so that e.g. a 6-ply evaluation uses 5, 4, 3, 2, and 
1-ply for the intermediate plies before using 0-ply for the final ply.  On 
the other hand performing a higher ply evaluation (esp. 3-ply and above) 
will become much slower.

If minimax is ever implemented, perhaps an option could be added allowing 
the user to either (a) use minimax or (b) perform all intermediate 
evaluations at 0-ply.

Thanks for helping me understand all this.  This topic is of significant 
interest to me.  I think it should be in the gnubg manual.  Once I 
understand it fully I'd like to volunteer myself to write an entry for the 
gnubg manual (unless someone else is already working on it; if so, let me 
know).

Chris