Hi Rick,
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 required.
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 required.
gnubg_ts0.bd - Two-sided database loaded into memory (by default a
6-chequer, 6-point database).
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.
To check what is installed:
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
________________________________
From: [email protected]
[mailto:[email protected]] On Behalf Of
Mueller Achim
Sent: 05 October 2009 06:58
To: gnubg-list
Subject: [Bug-gnubg] Cubeful Equities in GNU
Anfang der weitergeleiteten E-Mail:
Von: "Rick Janowski" <[email protected]>
Datum: 3. Oktober 2009 17:29:30 MESZ
An: <[email protected]>
Betreff: Cubeful Equities in GNU
Hi Achim,
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 player).
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 cases:
Dead-Dead Cube dead to both players
Dead-Live Cube dead to Player 1 but fully live to
Player 2
Live-Dead Cube fully live to Player 1 but dead to
Player 2
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
for download <ftp://ftp.demon.nl/pub/games/gnubg/databases/os/os13.bd> .
* 11.1.2 Download You may download the two sided
database with 6 checkers on 6 points from
ftp://alpha.gnu.org/gnu/gnubg/gnubg_ts0.bd.gz and the one sided database
with 15 checkers 6 points
fromftp://alpha.gnu.org/gnu/gnubg/gnubg_os0.bd.gz.
Regards,
Rick Janowski
--
achim mueller, ederweg 3, D-48431 rheine
+49 (0)5971 83767, +49 (0)163 8458340
-------------------------------------------------
pgp/gnupg key: 1024D/5DF3A722 (wwwkeys.de.pgp.net)
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
