Re: Error while generating bearoff database

[Øystein Schønning-Johansen]

And does it work if you add -c to the arguments to avoid the compression scheme? If it works you will end up with a 9GB table, but I'm far from sure it will be correct nor usable with GNU Backgammon.

(And I still don't recommend building this database at all)

-Øystein

On Tue, Oct 6, 2020 at 12:14 PM Øystein Schønning-Johansen <oysteijo@gmail.com> wrote:

Yep. In January 2005. The bug has not been resolved yet.

https://lists.gnu.org/archive/html/bug-gnubg/2005-01/msg00007.html

I have no intention of fixing it either, but maybe there should be a warning, or at least a check that stops the execution.. The worst thing is that I actually think the table is building just fine, and it is the compression scheme that fails. That is indeed unfortunate, since the user then has used a lot of resources and waiting and then ends up with nothing.

BTW: Does it work with 64bit builds?

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 bearoff database. 

-Øystein

On Tue, Oct 6, 2020 at 11:39 AM Ian Shaw <Ian.Shaw@riverauto.co.uk> wrote:

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-bounces+ian.shaw=riverauto.co.uk@gnu.org] On Behalf Of Øystein Schønning-Johansen
Sent: 06 October 2020 09:00
To: Joaquín Koifman <pamalejo@gmail.com>
Cc: gnubg list <bug-gnubg@gnu.org>
Subject: Re: Error while generating bearoff database

 

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)

 

 

On Tue, Oct 6, 2020 at 6:56 AM Joaquín Koifman <pamalejo@gmail.com> wrote:

Hi all!

 

When trying to generate a one-sided bearoff database greater than 13 points I get the following error. Do you know if there is any workaround?

 

Thanks in advance