CCRL Discussion Board

KBBKBN.TBS, is there an overflow error in it?

The KBBKBN.TBS does show for Draws -1846231405 ("-" does mean minus here) positions. There must be an overflow error in the counter for Draws in the program.

Please could someone of the people arround here, who do know about programming egtb, comment this? Am I right?

Yes, a negative count is a clear indication of overflow. Add a multiple of 2^32 to get the correct count.

I'm sure koistinen is right. In the P-ful endgames, Nalimov originally had 'lost' 2^32 drawn positions by cycling round a 32-bit integer - and even lost 2* and 3*2^32 positions in some. The check that this is so is to compare the index-range in Nalimov's code with the sum of won, lost, drawn and broken positions.
g

KBNKNN.TBS has the same issue. There are also no "Broken Positions" for "Black to Move" listed. Am I right, that "Broken Positions" are positions, where - for example - both Kings are in check? It could be, that the counter result with overflow was exactly was 0. So we have to expect, that other TBS Files are wrong too. We can not use them, to make statistics.

Pachnes wrote:KBNKNN.TBS has the same issue. There are also no "Broken Positions" for "Black to Move" listed. Am I right, that "Broken Positions" are positions, where - for example - both Kings are in check? It could be, that the counter result with overflow was exactly was 0. So we have to expect, that other TBS Files are wrong too. We can not use them, to make statistics.

Broken Positions are all the illegal positions, that still have an index in the index-scheme. For Nalimov that would only be Checks given to the side not to move, that could be blocked.
Eg White King on a1 and Black Queen on a3 (could be blocked by a piece on a2)

It is unlikely that it is exactly 0 or some multiple of 2^32. 1) 0 would mean a perfect indexing (which doesn't exist with Nalimov) 2) the chance for it being a multiple of 2^32 is 1/2^32 ... not very reasonable.
Probably there is some mistake in there as well.

KBBKBN.TBS, is there an overflow error in it?

The KBBKBN.TBS does show for Draws -1846231405 ("-" does mean minus here) positions. There must be an overflow error in the counter for Draws in the program.

in fact, this is only a problem with the windows 64-bit console generator, as the linux one has 64 bit integers for statistics logging, which is precisely why tbs are now checked with checksums rather than stats matching (as used to be done through dr. hyatt's site). further, the windows console .exe is limitted to 4v2 while the linux bin file (so i am lead to believe) is capable of 5v1,5v2,4v3 (the highest power 64 being 5 in all these cases). I have not tested this myself yet, having only recently returned to a position where i may begin generating 6 (and hopefully 7) man bases.

gambit3