Hi,
Thanks for your bug report. Let me have a guess.
In file makebearoff.c lines 216ff:
216 /* read distributions */
217
218 iOffset = 2 * iOffset;
219
220 nBytes = 2 * (nz + nzg);
221
222 if (fseek(pfTmp, iOffset, SEEK_SET) < 0) {
223 perror("fseek'ing temp file");
224 exit(-1);
225 }
Let me guess that iOffset in line 218 overflows. I've not checked this theory with any math, but that is still my theory.
Could be (I'm not sure as I have not tried) it helps if we change the type of iOffset to unsigned long instead of long. Or maybe even type size_t, which is probably the type the fseek() expects.
No, answering myself...The above suggested fix is not going to work. Checking the fseek() manual it actually expects long type offset as the argument. This is probably by design, such that you can easily move backwards in a file. Can you make a 64bit build? Maybe that will work.
However... (and this is a HUGE "however")
Building a full onesided bearoff database to the 14.point (or even lower) is actually not something you should do. It does not play better backgammon if you generate this file. A huge onesided non-contact database like this will misplay a lot of positions. It will hence not be usable for playing or rollouts. The neural network at 2-ply plays better! Use 2-ply neural network!
Best regards,
-Øystein
(BTW: I will not fix the bug)
