I'd appreciate it if any of you (especially Jorn and Jim) could have a quick look at it, and either correct any errors or suggest additions. I am especially hardpressed to find much information on th
wow! Excellent work! I'll bet 5 DKR that this is the problem! The first 40 bytes is the header: gnubg reads this line to find out what kind of database it is. The newline was added so one could easil
I've finished building and testing 0.14.3 packages and have uploaded them to Debian unstable. The new packages are built with as many of the options and prerequisites as are available in Debian, so s
Hello, still fairly new to gnubg, I wonder about gnubg's advice for X to move 21/16 6/5 (followed by 21/16 4/3, 21/16 3/2, 21/16 2/1) in this position: GNU Backgammon Position ID: rwEAAO62gQIEAA Matc
Yes, if you evaluate on n-ply with n > 1 you may end up at the bearoffdatabase at the deeper plies. The new code was supposed to be a sanity check for corrupted databases. Maybe one of the if-tests
Here you go: (gnubg) hint Considering move... Program received signal SIGSEGV, Segmentation fault. CopyBytes (aus=0x863f3e0, ac=0x54d028a4 <Address 0x54d028a4 out of bounds>, nz=4, ioff=1, nzg=0, iof
No, I don't agree. Here are some examples of settings that a compatible (or near-compatible): quasi random dice / no quasi random dice variance reduction / no variance reduction truncation at bearoff
Subscription is available from: http://mail.gnu.org/mailman/listinfo/bug-gnubg EvalInitialise, FindBestMove, and SetCubeInfo are as such unchanged. The entry point for cube decisions is GeneralCubeDe
The hash used in makebearoff is not very optimal. It uses used memory = number of entries * ( 6 bytes + sizeof ( bearoff data ) ) For example, the two sided bearoffdatabase has 8 bytes of data, so t
GNU Backgammon Position ID: zA7yBAPIM+YwQA Match ID : cAlyAaAASAAA +24-23-22-21-20-19--18-17-16-15-14-13-+ O: Woolsey +-1--2--3--4--5--6--7--8--9-10-11-12-+ X: Readers The following was posted by on
Does your makefile include br1.c in COMMON_SOURCES? That's where the function is defined. If br1.c doesn't exist, it is constructed by doing: br1.c: makebearoff makebearoff1 if [ ! -f br1.c ]; then \
Hi, I'm having problems compiling the CVS version. It fails with: eval.o(.text+0x89d):eval.c: undefined reference to `BearoffInitBuiltin' I do have bearoff.c and .o in SOURCES and OBJS in Makefile, r
Still getting that one. (changelog 1.795, makebearoff removed from Makefile) This is the Makefile as it is now: CC = gcc CFLAGS = -fnative-struct -Os -Wall $(DEFS) $(INCLUDE) DEFS = -DHAVE_CONFIG_H
The 1-sided database gives the most efficient bearoff by minimising the average rolls required. The "using normal distribution" 1-sided database that Isambard mentions in other posts does only this,
The problem is that the 2 sided bearoffdatabase is only valid for money games (its exact for that). In those situations it will go right to the DB. If you take your same position and turn it into a
Hi all! There's a bug in makebearoff when building one sided databases without gammon distributions. C:\Program Files\gnubg>makebearoff --one-sided=5 -g --outfile=myfile.bd One-sided database Number
Actually the performance is worse using the databases as the I/O takes more time than a neural net evaluation. Joseph did some comparisons between the 12pt bearoffdatabase and the neural net. For ex
Fair nuff... it's actually just \o and \O, but I added them in all the same. I didn't think to do it since I just wanted to get the thing out. He actually sent me a link to a detailed interview with
The cube value is indifferent. The equities in the bearoffdatabase are normed to a 1-cube anyway. I do use the correct cube position (centered, owned, or unavailable). Gammon prices should matter he