On Tue, Oct 06, 2020 at 09:59:20AM +0200, Øystein Schønning-Johansen wrote:
> A huge onesided non-contact database like this will misplay a lot of
> positions.
Is it really that bad ?
I thought that, as long as one does not use shortcuts like the
--no-gammons and --normal-dist options,
On Tue, Oct 06, 2020 at 09:59:20AM +0200, Øystein Schønning-Johansen wrote:
> 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
On Tue, Oct 06, 2020 at 12:14:19PM +0200, Øystein Schønning-Johansen wrote:
> maybe there should be a warning, or at least a check that stops the
> execution.
Such a check was added a few month ago, after a similar bug report (I
don't remember if it was in this list or by some other mean) and
Yes! Good point actually. I did indeed assume that someone would build it
for use with GNU Backgammon and that assumption might not be right.
I can actually admit that I have been building long one-sided databases
myself (not using makebearoff tool) to get good heuristic moves and
probability
Øystein Schønning-Johansen wrote:
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.
I'm not saying that anyone should put in the time to fix this bug. But
the last time I tried to
Hi,
Thanks for your bug report. Let me have a guess.
In file makebearoff.c lines 216ff:
216/* read distributions */
217
218iOffset = 2 * iOffset;
219
220nBytes = 2 * (nz + nzg);
221
222if (fseek(pfTmp, iOffset, SEEK_SET) < 0) {
223perror("fseek'ing
