[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnubg] Bug: Double/Beaver
Christopher D. Yep
Re: [Bug-gnubg] Bug: Double/Beaver
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
> 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
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
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
- [Bug-gnubg] Bug: Double/Beaver, Christopher D. Yep, 2003/08/20
- Re: [Bug-gnubg] Bug: Double/Beaver, Joern Thyssen, 2003/08/21
- Message not available
- [Bug-gnubg] Japanese Locale Problem for Windows 2000, Yoshito Takeuchi, 2003/08/23
- Re: [Bug-gnubg] Japanese Locale Problem for Windows 2000, Nardy Pillards, 2003/08/23
- Re: [Bug-gnubg] Japanese Locale Problem for Windows 2000, Yoshito Takeuchi, 2003/08/24
- Re: [Bug-gnubg] Japanese Locale Problem for Windows 2000, Jim Segrave, 2003/08/25
- Re: [Bug-gnubg] Japanese Locale Problem for Windows 2000, Joern Thyssen, 2003/08/25
- Re: [Bug-gnubg] Japanese Locale Problem for Windows 2000, Nardy Pillards, 2003/08/25
- Re: [Bug-gnubg] Japanese Locale Problem for Windows 2000, Yoshito Takeuchi, 2003/08/25