[Top][All Lists]

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

Re: [Bug-gnubg] Idea for encoding 2-sided database

From: Joern Thyssen
Subject: Re: [Bug-gnubg] Idea for encoding 2-sided database
Date: Tue, 29 Mar 2005 13:50:55 +0000
User-agent: Mutt/

On Tue, Mar 29, 2005 at 10:10:55PM +1200, Joseph Heled wrote
> I still believe the 2 sized database is a non issue as the one-sided 
> database is sufficient. Can anyone provide some meaningfully counter 
> examples?

The two sided database is excellent for cubeful equities.

> I think a more important issue is how to get better cube actions in bearoff 
> at any score. This is a real hard problem, but when done may uncover a not 
> insignificant source of gnubg errors.

Actually gnubg uses the cubeful money equities to calculate cubeful
match equities.

Janowski's formulae is

Eq(cubeful) = x Eq(fully live) + (1-x) Eq (dead)

Since Eq(cubeful) and Eq(dead) are available from the database and
Eq(fully live) can be calculated easily, we can isolate x.

This gives us the exact x for money game. The idea is now to use this
exact x for match play to calculate Mwc(fully live) for the specific match

Mwc(cubeful) = x(money) * Mwc(fully live) + (1-x(money)) * Mwc(dead)

instead of using a fixed empiric value for x. 

I must admit I did not do any extensive tests comparing MWCs calculated
using the fixed empiric value for x, the MWCs calculated using the money
value for x and rollouts, but my tests while I programmed this showed
very improved MWCs compared to rollouts.

Of course, all the above only works when the position is available from
the two sided database. Another issue is calculating cubeful equities
for other bearoff and race positions. I know you had some ideas
calculating x from average number of rolls and match score.


Attachment: pgpB7I6KvZr0C.pgp
Description: PGP signature

reply via email to

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