|
From: | Øystein Schønning-Johansen |
Subject: | Re: Error while generating bearoff database |
Date: | Tue, 6 Oct 2020 12:38:14 +0200 |
Yep. In January 2005. The bug has not been resolved yet.https://lists.gnu.org/archive/html/bug-gnubg/2005-01/msg00007.htmlI 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.-ØysteinOn 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
[Prev in Thread] | Current Thread | [Next in Thread] |