On Sun, Mar 24, 2019 at 03:17:07PM +0100, Øystein Schønning-Johansen wrote: > Yes. Really cool. I have earlier seen significant differences between > one-sided and two-sided race evaluation, but this is not one of the > positions where it is off.
I suppose it helps that the opponent's position is a few-rolls position and more balanced long races would not do as well. > Some years ago, I used the same algorithm to calculate a full two-sided > database for 15 checkers on 6 points. I can share it by bittorrent, or the > generating code. The data file is 11 GB. Would it be usable as is with the current gnubg ? Would any file larger than 2 Gb be, anyway ? I would be interested in the generating code, at least as an example that handles the kind of issues below. Are you, Øystein, or other readers, familiar with gnubg's bearoff databases format ? (I am not). Would it be enough to compile gnubg with the appropriate _FILE_OFFSET_BITS=64 / _LARGEFILE_SOURCE / _LARGEFILE64_SOURCE #defines and possibly some limited variables type changes in the code to be able to use bigger databases, or are there more subtle limitations in the current code ? Similarly, to create a one-sided database for, say, 15 men up the 8 point plus 2 up to the 18 point, or a similar subset of "plausible" positions, would it be enough to find an adequate indexing scheme ? _______________________________________________ Bug-gnubg mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnubg
