Hi Thanks for your answer. I guess that if you use the OSD by selecting only the expected roll minimizing choice, then this can lead to mistakes (as you note). However, I guess what I'm getting at is
Hi Isembard, The 1-sided database gives the most efficient bearoff by minimising the average rolls required. Sometimes, this isn’t the best play. When the opponent is close to the end, it may n
After a bit of testing and a larger bit of patience I've been able to build the 6x10 two-sided bearoffdatabase. My AMD XP2000+ spent about nine hours and forty minutes, using the default hash settin
I set up this position and did an evaluate. Gnubg crashes when you OK the eval window. Gnubg-no-gui crashes as soon as it has finished outputting the data. Hint seems to work OK. The output from bear
I tested out bearoffdump on a test database using normal distribution format and got the following strange output (running on a 64bit Debian system). I was expecting a similar format to a non-ND data
Yes, it is diminishing returns, but some of us pedants like to be able to use large databases from time to time, mainly to study epcs. I think this is true for playing games, but not necessarily so
I have since checked the mainline and re-applied my patchs and it runs fine. set gnubgid 3wYAANjsGwEIAA:MAFpACAAAAAA hint 1 in my local build gives a crash (gdb) where 0 MakeInt (pbc=<value optimized
set gnubgid 3wYAANjsGwEIAA:MAFpACAAAAAA hint 1 in my local build gives a crash (gdb) where 0 MakeInt (pbc=<value optimized out>, nPosID=3272738968, arProb=<value optimized out>, arGammonProb=0xbfeb9
The weights and basic bearoff databases are installed by default. Click on Analyse...Evaluation Engine to check what you have installed. If gnubg plays a decent game of backgammon, then the weights a
- tried regenerating the sgfl.c file and had the same outcome. - "/usr/include/sys/signal.h:207: parse error before `1'" + this was the error message produced during compilation of sgfl.c prior to ad
Yes, but my gammonless file si still 1,339,230 bytes, However, the index takes up 434,112 bytes, so the actual bearoff distribution is 905,110 bytes which is in line with your 1,126,324 bytes. I've j
Jonathan Kinsey wrote: > Michael Petch wrote: >> I am wondering if there's any connection to the weird cube decisions Neil >> Robins discussed previously: >> http://www.bgonline.org/forums/webbbs_con
Surely, therefore, at least 1-ply or higher should see the recube and the then dead cube situation and go to the DB for an exact valid value. -- Original Message -- From: Michael Petch To: Neil Robin
I should have said “The problem is that the 2 sided bearoffdatabase is only guaranteed to be valid for money games”. There are match play situations where it is valid (dead cubes etc) On
I've committed a patch which removes the assert. I've also reduced the size of each index entry for compressed database w/o gammon distributions. This means that if someone is using a gammonless ones
I have some plans about rewriting a lot of the engine; it shouldn't be visible for the users, but make it easier for the programers. It might be able to squeze your suggestion in. Jim Segrave is the
Hi, I've added a new program bearoffdump, which can be used to dump information from gnubg's bearoff databases, e.g., bearoffdump gnubg_ts0.bd 456543 -- 8< -- 8< -- Bearoffdatabase: gnubg_ts0.bd Pos
I think we might need some input from Joern here. br1.c is under CVS, but that version doesn't have the static data table in it (it's only a few lines long). So if make runs, the if [ ! -f br1.c ]; t
I don't have a Mint distribution installed, but on Ubuntu (it should be very similar), makehyper in present in /usr/games and can create an hypergammon database. It creates it in the current director
It's similar to a one-sided bearoffdatabase, except that the bearoff distributions are not calculated exact, but rather through a one sided rollout. That is, instead of taking all possible 21 rolls