[Top][All Lists]

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

Re: [Bug-gnubg] Question About Rollout

From: Robert-Jan Veldhuizen
Subject: Re: [Bug-gnubg] Question About Rollout
Date: Wed, 14 Nov 2007 15:32:15 +0100

Hi Mochizuki and Massimiliano,

Looks like the issues got confused here a little.

First of all, GNUbg's win/gammons/backgammons breakdown is based on what happens or would happen if the game were played to completion. A double/pass is therefore not the same as a single game win. A double/pass will be scored in the w/g/bg columns using the evaluation at that point.

So, like Christian's example, a double/pass could happen with 60% winning chances and 40% gammon chances. Cubeful it will be scored as +1 (in EMG), but it won't be scored in the w/g/bg breakdown as a 100% single win, but rather using the actual evaluation figures.

Second, GNUbg's cubeful rollout is what you want it to be, whether it's a cube decision or checker play decision. It plays with a fully live cube, and uses cubeful evaluations along the way (assuming that box is checked in the settings, as it should be for anything cubeful).

On Nov 13, 2007 11:14 AM, Massimiliano Maini <address@hidden> wrote:

1- When you say "cubeless", do you mean that the game will be truncated
right after the very first double decision, if any? I understand your
example of a double/pass, but what about a double/take situation?

A cubeful rollout trial will be truncated whenever GNUbg thinks it's a (re)double/pass. The reason is simply this: the cubeful equity is known at that point: +1 in EMG. Also, in a real game, play would be over when one side passes: GNUbg works the same way. For the w/g/bg breakdown and cubeless equity figure, the values from the cube evaluation at that point are used.

When a (re)double/take happens, the trial just continues, since the cubeful equity isn't known at that point. The new cube value and position will be taken into account ("fully live cube").

2- At the end of the trials, the computed "cubeless" figures will
lead to a "cubeless" equity that will be translated into a cubefull
equity via the janowski formula, right?

No. GNUbg currently has no such feature. Either it's a cubeless rollout and only gives you a cubeless equity, or it's a cubeful rollout and uses a live cube to determine cubeful equity (not a Janowski approximation).

 It might be a nice feature though, to have GNUbg give us a Janowski cubeful equity in cubeless rollouts, handy for those positions where GNUbg's cube actions in a rollout lead to many (quick) incorrect double/passes (with the associated wrong w/g/bg breakdowns...). I think Jellyfish uses this approach, and Snowie also has it as a feature ("cubeful" equity in a cubeless, i.e. no live cube rollout).

In Mochy's example, the W/G/BG%
are the "cubeless" results of the rollout, the CL is the "cubeless"
equity and CF is comuted via Janowski formula?

So, no.

> > Rollout details:
> > Centered 1-cube:
> >   0.669 0.146 0.002 - 0.331 0.078 0.003 CL  +0.405 CF  +0.621
> > Player player owns 2-cube:
> >   0.670 0.152 0.001 - 0.330 0.077 0.003 CL  +0.854 CF  +0.574

3- Any idea why a simple "full cubefull rollout" approach is not implemented ?
I mean letting gnubg play against himeself cubefull and record the outcome.

So, this is what a GNUbg  cubeful rollout does.

I suspect this comes from the fact that its result would not be a W/G/BG%
but more an equity (for money) or a MWC (for match), but hey, these
are what matters ...

The w/g/bg are still basically the same (as they would be in a cubeless ("dead cube") rollout), except that any (re)double/passes during the rollout will use the evaluation breakdown at that point ( i.e. truncated). The "live cube" is reflected in the cubeful equity.

Another reason is that the current method, truncating at double decisions,
should/could "reduce the variance" (provided the evaluation is good).

So the truncating only happens when it's a (re)double/pass. This reduces variance and speeds up the rollout.

Robert-Jan Veldhuizen

reply via email to

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