GNU ID: /38AAAC49wAAAA I don't think you need a long rollout for this position. I think I can give you the "ultimate rollout". A 16ply gives me 0.440498 (or -0.119004 eq). It takes only a few second
The two sided database is excellent for cubeful equities. Actually gnubg uses the cubeful money equities to calculate cubeful match equities. Janowski's formulae is Eq(cubeful) = x Eq(fully live) + (
Salut gnu-bg-list, I'm new in using GNU and did install the lastest version of GNU under Windows. After that I did the download of the new bear-offdatabase: os13.bd This file is now on my hdd on a se
I agree with Øystein, but would add that you can speed up rollouts (particularly 2-ply) if you select to stop at the databases. Also, the databases are the only way to see the effective pip count,
The race neural net is really close to 'just as good', and the race neural net is much faster than accessing a database on the harddrive. You can of course make a bigger database for longer races. I
I think you will find there are not enough "gin" positions to make this worthwhile. But it will be nice to be prove wrong. -Joseph Could we reduce the size of the two-sided database by omitting gin p
I'm not at all sure what the structure of the bearoff files is. You might be right that there's a separate index with pointers, in which case it would be possible to have a value indicating no data (
Hello Ian, well, that´s why i wrote which file systems i used. NTFS and even FAT32 can handle much larger files than 2,1 GB. http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en
There is a limit on the file size that the PC file system can handle. It is 2^31 bytes = 2147483647. I assume it's 2^31 instead of 2^32 because the 32nd bit is used as the +/- sign. Anyway, this puts
Behalf at 2 Ok, I talked with Neil earlier on and clarifeid what he was suggesting. First of all, he agrees about the idea of a single-sided race DB. I apparently misunderstood, as he didn't bring u
I still believe the 2 sized database is a non issue as the one-sided database is sufficient. Can anyone provide some meaningfully counter examples? I think a more important issue is how to get better
[snip] Yes. Yes, the gammon and bearoff distributions do not overlap, or the overlap is negligible. Thx, nice to hear others agree on that :-) Jørn Attachment: pgp39OsZZ8xQQ.pgp Description: PGP sig
The best instructions for working with databases are here http://www.gnu.org/software/gnubg/manual/html_node/Bearoff-databases.htm l#Bearoff%20databases. If these don't help you, get back to us. Bas
This looks like a bug to me. The ply difference should not be that much, and the result should not depend on which bearoffdatabase you 're using. -Øystein -- The information contained in this messa
Hmmmmm.... this sounds familiar. Hasn't this been reported before? I may be wrong but wasn't it Morten Wang who reported this problem years ago? Or maybe it was Ian? If I remember correctly Ian (Shaw
GNU this has I have seen mistakes. I have been using Dueller to play matches between the two programs, and have had both programs analzye the matches. Snowie has highlifghted a few mistakes which we
Again, this is not entirely new. The suggestion to enhance the race DB is based on the assumption that the bot misplays those positions. I would like to see the evidence for that. I think I will star
[access to the ftp server is complicated] Wouldn't it make sense to put everything at the same place (like at www.gnubg.org). The training/bechmarking data is about 100MB. Maybe ten years ago it was
I would very much like to do some changes to gnubg.bd. Of course, I'll try to keep backwards compability. Very shortly, gnubg will be able to read large one-sided databases and large two-sided databa
What are the trade-offs with specifying different hash sizes? Is there any difference between the terms "size of hash" used for 2-sided, and "size of cache" used for 1-sided? Is there any interaction