I do exactly the same for the bearoff-databases. Besided storing the probabilities for bearing off all chequers the probabilities for bearing at least one chequer off are stored. Extremely good gammo
Hmm, at work... Since the position you posted is from the in-memory two-sided bearoffdatabase and doesn't use neural net, you can check MD5 checksums of the database. The correct checksums are in th
gnubg is using the one-sided database for this position (gnubg_os0.bd). It could be one of those positions where the one-sided bearoffdatabase is wrong. I'l check with my larger two sided one when I
This was a bug in some code I committed Sunday. There is nothing wrong with the bearoff databases, this was a bug in the evaluation routine. I've committed a fix now. Jørn
No magic involved here. getBearoffGammonProbs takes the position of the side wanting to bear one checker. (Since it is a bearoff, all other 19 points are know to be empty, so only 6 are needed). It r
In the normal one-sided bearoff databases we store an array of probabilities: the probability to bear off in 0 moves, in 1 move, in 2 moves etc etc. For example, GNU Backgammon Position ID: qm3bAADMX
Makebearoff will create databases bigger than 2gb but GNUBG apparently can't use them. As far as I am aware at this point in time the 2gb limit is still an issue. As you know there is a caveat in the
Hi, I was wondering if I can get a two sided Bearoffdatabase that is bigger than 6x11. Makebearoff won't create any two sided database bigger than 2GB. If such a database was available on a disk I w
The new 5MB dataase (http://users.skynet.be/bk228456/gnubg_ts0.exe) covers 6 chequers on 6 points. There is source code for a program that can generate larger databases (I'm don't think it's included
Hi all, I'm in the process of generating one-sided bearoff databases for gnubg. The bearoff databases generated contains probabilities for bearing off and the probabilities for bearing more than one
Gnubg exits with no warning when I am setting up a position, or reaches a position during play. It occurs when the position is outside the in-memory db, but within the one-sided db on disk. For insta
I've had a look - the one sided bearoff db can have two forms: Uncompressed (every position has a full entry - either 64 bytes or 128 bytes, containing 32/64 float values (64 if gammon probabilities
As an interesting side note I was actually in doubt how to handle gammons in the one sided database. When the database is generated the best moves are found by selecting the move with the lowest ave
I suppose it helps that the opponent's position is a few-rolls position and more balanced long races would not do as well. Would it be usable as is with the current gnubg ? Would any file larger than
Thanks Mishkin, I have successfully downloaded the three-chequer hypergammon database from the link below. The link at http://gnubg.org/index.php?startpos=10 "One-sided race database reaches the midp
large 1-sided bearoff db, just the two in memory and the large version of the 2-sided db. 1-sided db? That's what I thought from reading gnubg's output from amalysis/evaluation engine. However, the
Build 02Dec01, WinME. (with "perfect" bearoff db gnubg_ts0.bd dated Dec01, size 6671kb). I'd thought the bearoff problems had cleared up after I reloaded the program and database with the late Dec01