Actually it's slower! The two-sided database tend to grow very fast with the number of points and chequers. I've got Hugh Sconyer's full bearoff databases for 15 chequers vs. 15 chequers on 6 points,
Basically it's 32 unsigned short ints for each position. The current one-sided bear-off database is for 15 chequers on the 1-6 points, a total of N(21,6)=54264. Each of the 32 integers represent the
Ugh. Most compression schemes work on a sliding window over the input stream, so you'd have to set re-sync points throughout the compressed file and seek to there, then walk forward to the data you w
You’re right, Øystein. We came across this problem years ago when I tried to generate large databases. The thread is still somewhere in the archives. Cheers, Ian From: Bug-gnubg [mailto:
You’re right, Øystein. We came across this problem years ago when I tried to generate large databases. The thread is still somewhere in the archives. Cheers, Ian From: Bug-gnubg [mailto:
If we try to compress it, it'll be much harder to read it. We can easily compress the current gnubg.bd since it's read into memory and we can just read it with functions from libz. However, for the n
Which bearoffdatabase do you use for this? The problem with the porting is that bearoff databases. I ported this as well but I had to use the bearoffdatabase from Joseph, and then where was sudden
You’re right, Øystein. We came across this problem years ago when I tried to generate large databases. The thread is still somewhere in the archives. Cheers, Ian From: Bug-gnubg [mailto:
(I'm forwarding this as someone in the list might be able to provide more information on the subject of database recommendations) -- Hi Jim, generate little reference Well, GNU doesn't really suffer
The actual position is not stored in the database. THe positions are just enumerated in a convinient way, for example, one-sided bearoff with 15 chequers on 6 points: Position# Position 0 zero cheque
You’re right, Øystein. We came across this problem years ago when I tried to generate large databases. The thread is still somewhere in the archives. Cheers, Ian From: Bug-gnubg [mailto:bug-gnubg-
I just tried a little crude perl script to see how many values are unneeded in the database. My plan was: the probability of clearing in n rolls is 0, if the number of chequers is more than 4*n. In t
Hi, Yes, I really agree with Joseph here. Can anyone provide any race positions where it misplays the positions? If this is a problem I think we should rather make Joseph's osr (*) algorithm availabl
I'm not saying that anyone should put in the time to fix this bug. But the last time I tried to generate a database wasn't for use with GNUBG. It was for independent mathematical investigations.
And again: You should not build such a one-sided database in the first place. You will not get a better player if you use such a large bearoffdatabase. I'm not saying that anyone should put in the t
Argh, I'll try to finish the mail this time (after accidentally pressing 'ZZq') The equities are the same within 0.0001. If you want the fully correct bearoffdatabase I suggest you generate it yours
hi all, what are glib and gobject? where can i find them? shall i put them along with gnubg_os0.bd in the same folder as boa.exe? and then double click boa.exe or run it from windows command prompt?
Such a check was added a few month ago, after a similar bug report (I don't remember if it was in this list or by some other mean) and will be in the next release : % ./makebearoff -o 15 -f gnubg_os0
I tried to recreate the bearoffdatabase and noticed some differences which could be due to rounding, but already at position #47 there were some significant differences. My workings for position 47