Stockfish bitbase

[michiguel]

I made a md4sum of KBKBitbase[] after compression with and without the suggested patch.

Without the patch:
MD5 Checksum for bitbases: d0a7a886d3f237b62c26e09409c3bf41

with the patch:
MD5 Checksum for bitbases: 5003c4ef8d60d67b19da63587f9ed74f

The patch does indeed make a difference!

-Øystein
from endgame.cpp:

Code: Select all

void init_bitbases() {
  gchar *checksum;
  generate_kpk_bitbase(KPKBitbase);
  checksum = g_compute_checksum_for_data( G_CHECKSUM_MD5, KPKBitbase, 24576 * sizeof( uint8_t ));
  printf("MD5 Checksum for bitbases: %s\n", checksum );
  g_free( checksum );
}

Now the burning question is:
"Which one is correct?"

When I generated a KPK bitbase in Gaviota (before the TBs) I debugged them with a forward search. In other words, you go position by position and do a 1 ply search. The result of that search, has to be the same as the one statically stored. If this test passes, everything is fine. It is extremely difficult to get it right the first time (at least for me).

Miguel

[Dann Corbit]

The patch does indeed make a difference!

That means that there could indeed be a bug somewhere. I'll have a look at it. Thanks to everyone for making me aware of this!

This seems a simple idea to identify it:

Do a binary string compare of the two generated sets.

At the first place of difference, create a position that utilizes those bits (this assumes that you have some way to invert the function).

Then take that position and feed it to some known EGTB engines like Nalimov's and Balicora's and see which one disagrees.

[Tord Romstad]

The patch does indeed make a difference!

That means that there could indeed be a bug somewhere. I'll have a look at it. Thanks to everyone for making me aware of this!

This seems a simple idea to identify it:

Do a binary string compare of the two generated sets.

At the first place of difference, create a position that utilizes those bits (this assumes that you have some way to invert the function).

Then take that position and feed it to some known EGTB engines like Nalimov's and Balicora's and see which one disagrees.

The positions were so few (45 in total) that I just inspected them manually. It appears that the original code is correct and kongsian's code incorrectly classifies a few won positions as drawn. The problem seems to be that it doesn't handle positions with double pawn pushes correctly. Here's one example:

[d]8/8/8/8/8/8/P1k5/K7 w - -

Kongsian's code classifies this as a draw, but white of course wins by 1. a4.

[kongsian]

The patch does indeed make a difference!

That means that there could indeed be a bug somewhere. I'll have a look at it. Thanks to everyone for making me aware of this!

This seems a simple idea to identify it:

Do a binary string compare of the two generated sets.

At the first place of difference, create a position that utilizes those bits (this assumes that you have some way to invert the function).

Then take that position and feed it to some known EGTB engines like Nalimov's and Balicora's and see which one disagrees.

The positions were so few (45 in total) that I just inspected them manually. It appears that the original code is correct and kongsian's code incorrectly classifies a few won positions as drawn. The problem seems to be that it doesn't handle positions with double pawn pushes correctly. Here's one example:

[d]8/8/8/8/8/8/P1k5/K7 w - -

Kongsian's code classifies this as a draw, but white of course wins by 1. a4.

Yes, that's right. Once I fixed the incorrect classification, the bitbase[] turns out to be the same. Sorry for the false alarm.

Kong Sian