What you need to do is download the databases you want and
put them in the gnubg directory, unzipped of course. Then you rename them as
listed below, to govern how gnubg uses each file.
Gnubg uses up to four bearoff databases, and identifies
them from the filename.
gnubg_os.bd - One-sided database read from disk as
To check what is installed:
gnubg_os0.bd - One-sided database loaded into memory (by
default a 15-chequer, 6-point database)
gnubg_ts.bd - Two-sided database read from disk as
gnubg_ts0.bd - Two-sided database loaded into
memory (by default a 6-chequer, 6-point
This allows you to choose
how large a database you want to load into memory, gaining speed at the expense
of memory usage. If gnubg can't find the position in memory, it will then look
it up in the file stored on disk.
Select Analyse...Evaluation Engine (or, from the command line, type "show engine")
I hope this answers your question.
Finally, I'll just take this opportunity to express my appreciation and thanks for the contribution you've made to backgammon theory and the redevelopment of strong bots.
-- Ian Shaw
Anfang der weitergeleiteten E-Mail:
Oktober 2009 17:29:30 MESZ
Cubeful Equities in
I recently downloaded GNU backgambmon and was
gratified that the programmers have made use of my work on doubling cube
models and have made appropriate acknowledgement.
As you may
be aware, I did quite a lot of work with Snowie over a short period six or
seven years ago in helping them develop cubeful models for matches. The
general approach, for both money and match play, was to estimate equities
where the cube is fully dead or fully live for both players. The effective
equity was then interpolated between these two extremes based on cube-usage
factors (dependent on future volatility and other similar factors). The
developers of Snowie considered both the simple case of a cube usage value
(ie, for both players) and two separate values (ie, separate for each
Looking over my work more recently, I came to the
conclusion that my way of looking at the refined model (with separate values
for cube usage for both players) was flawed to some extent, particularly
with regard to cube-centred equities. I had originally considered
interpolation only between the two extreme cases of dead-dead and live-live
cube values. In reality there are four extreme
Dead-Dead Cube dead to both
Dead-Live Cube dead to
Player 1 but fully live to Player
Live-Dead Cube fully live to
Player 1 but dead to Player
Live-Live Cube fully live
to both players
These four points may be imagined as four corners of
a rectangle, with Player 2 cube-liveness being the measure on the axis of
Dead-Dead to Dead-Live. Similarly, Player 1 cube-liveness being the measure
on the axis of Dead-Dead to Live-Dead.
I would be interested in your
ideas on the value of developing this approach.
Could you advise me on how I can incorporate
within GNU the following downloads from your website:
* One-sided race database reaches the midpoint
- A one-sided race database that extends to the 13-point is now available
achim mueller, ederweg 3, D-48431 rheine
+49 (0)5971 83767, +49 (0)163 8458340