BGonline.org Forums

Two concrete examples of using "View Statistics"

Posted By: Timothy Chow
Date: Wednesday, 20 January 2010, at 1:43 a.m.

I've been trying to persuade others of the value of the "View Statistics" feature of GNU, so far with limited success, probably because I myself am still trying to figure out the best way to use that information. Let me make another attempt here, using two concrete positions as examples.

The first example is one I've already used before, namely the C-note position, but I now have what I feel is a clearer presentation of it. Blue is on roll and we are interested in whether White can take Blue's cube.

The score (after 0 games) is: White 4, Blue 8 (match to 13 points)

White39

Blue83

Position ID: vwcAALRtOwARAA Match ID: UQmgAUAAQAAA

Let's first review the "standard" approach to this take decision. We first note that White's raw take point is 23%. The bots tell us that White's cubeless win percentage is 16.6%. Obviously, there are no gammons to consider. The only thing left is recube vig. The bots assure us that White has enough recube vig to give White a take, but following the standard approach, there seems to be no other information we can extract from the bot to explain why the recube vig is so high.

But now suppose we "View Statistics." We first learn that White's actual wins (as opposed to White's cubeless wins) are 18%. We also learn that in most of these cases, White manages to get in a redouble and a take first; in fact, White wins 13% of all games with the cube on 8. Thus White has 13% effective gammon wins. Similarly we learn that White has 24% effective gammon losses (i.e., White losses with the cube on 8). Knowing that the price of a gammon win is 0.77 and the price of a gammon loss is 0.12, we can then calculate

18% + (0.77 * 13%) - (0.12 * 24%) = 25%,

which is greater than our raw take point of 23%, so White has a take. I don't know about other people, but I feel that this calculation improves my understanding of the position. The gammon prices of 0.77 and 0.12, which at first sight are irrelevant because there are no gammons, are actually important because they help us quantify the recube vig. The fact that 0.77 is much bigger than 0.12 helps explain why White can aggressively recube when things are going his way.

For my second example, I'm going to take one of Phil Simborg's positions from last month. (By the way, thank you Stick for putting the archives back online—I couldn't have found this position again otherwise!)

The score (after 0 games) is: White 0, Blue 0 (match to 3 points)

White68

Blue53

Position ID: u90GAAJvNzMAAA Match ID: QYloAAAAAAAA

# Ply Move Equity
1 R 8/5* +0.264
 0.664 0.006 0 - 0.336 0.048 0.001 0.288 0.264 0 0 0 - 0 0.001 0 0.001 0.001
Full cubeful rollout with var.redn.
1296 games, Mersenne Twister dice gen. with seed 846338333 and quasi-random dice
Play: world class 2-ply cubeful prune [world class]
keep the first 0 0-ply moves and up to 8 more moves within equity 0.16
Skip pruning for 1-ply moves.
Cube: 2-ply cubeful prune [world class]
2 R 4/2 3/2 +0.248 ( -0.016)
 0.683 0.001 0 - 0.317 0.001 0 0.366 0.248 0 0 0 - 0 0 0 0.001 0.001
Full cubeful rollout with var.redn.
1296 games, Mersenne Twister dice gen. with seed 846338333 and quasi-random dice
Play: world class 2-ply cubeful prune [world class]
keep the first 0 0-ply moves and up to 8 more moves within equity 0.16
Skip pruning for 1-ply moves.
Cube: 2-ply cubeful prune [world class]

Phil was wondering why 8/5* came out on top despite winning fewer cubeless games, losing a lot more cubeless gammons, and winning only a tiny number of extra cubeless gammons compared to the alternative of 4/2 3/2. Again, the answer lies in recube vig, but following the standard approach, it is not clear how to get the bot to tell you anything more than "trust me, if you don't hit then you're giving White too much recube vig."

But now let's "View Statistics." Because of GNU's limited support for this feature, I had to kludge this by rolling out White's cube decision after Blue plays 8/5* and, separately, White's cube decision after Blue plays 4/2 3/2. In each case I rolled the game out 15552 times; this might seem a lot, but GNU currently doesn't seem to provide variance-reduced statistics so we have to compensate by increasing the number of trials.

One thing we can spot immediately from the statistics is that if Blue plays 8/5* then White's cube efficiency is only 7%, whereas if Blue plays 4/2 3/2 then White's cube efficiency is 41%. ("Cube efficiency" here means the percentage of White's subsequent redoubles that Blue takes.) That already gives us some quantitative feeling for the difference in recube vig.

The next thing we can check is whether Blue's actual win percentage is close to his cubeless win percentage. I found that after 8/5*, Blue won 10310/15552 = 0.663 of the time, and after 4/2 3/2, Blue won 10629/15552 = 0.683 of the time. So cubeless wins are basically the same as actual wins and we haven't gained any new insight here.

Now comes the important part: How often does Blue win/lose 4 points? Note that 4 points can arise in two different ways: a 4-cube, or a gammon with a 2-cube. As far as equity calculations are concerned they are equivalent, so I will lump them together and again call them effective gammons. We find that (ignoring backgammons):

After 8/5*, Blue wins 181/15552 = 0.012 effective gammons and loses 864/15552 = 0.056 effective gammons.

After 4/2 3/2, Blue wins 722/15552 = 0.046 effective gammons and loses 1631/15552 = 0.105 effective gammons.

We see that 4/2 3/2 loses a lot more effective gammons (and these are essentially all single losses with the cube on 4), and this is the main reason why it's worse than 8/5*. We could do a gammon price calculation to verify that the extra effective gammon losses really do outweigh the extra games won, but I won't bother; I think you get the idea.

Hopefully these two examples illustrate the insight that can be gained by "Viewing Statistics." If others agree with me that these statistics are useful, then perhaps we can collectively lobby the bot programmers to provide better support for this feature. Currently, in GNU, the statistics have an unpleasant tendency to vanish permanently as soon as you click the wrong button (and they are not savable to the SGF file), and they are not variance-reduced.

Post Response

Subject:
Message: