[Top][All Lists]

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

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

From: Christopher D. Yep
Subject: Re: [Bug-gnubg] Bug: Double/Beaver
Date: Fri, 22 Aug 2003 06:31:24 -0400

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


[*] 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).


reply via email to

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