bugs in hash tables

[Michael Sherwin]

I was intrigued by the beauty of the problem and the failure of strong engines to find the right move b8a6 with deep search. So I added some code to the endgame knowledge base of my engine as described by the following pseudocode:

Code: Select all

//nobles are N,B,R,Q
if(lone rivalside king)
{
    if(all ownside pawns on one rookfile)
    {
         if(ownside has no nobles or only bishop of wrong color)	
        {
            if(rivalside king stands on or adjacent to queening square)
                return DRAW;
        }
    }
}
//Q. Why do the indents disappear?

Not surprisingly, my engine now finds b8a6 at search depth of 3.

[hgm]

It is correct that I only need the last 50 non reversable moves for repetition but I want also to support analyze when the human can take back moves and having one big table for all the game is the simplest solution.

OK, I see. To implement takeback I remember all moves since the game started (which you have to do anyway, as a hashkey alone doesn't allow you to reconstruct the position). An undo is than performed as starting a new game, and force the first N-2 or N-1 moves.

[Uri Blass]

It is correct that I only need the last 50 non reversable moves for repetition but I want also to support analyze when the human can take back moves and having one big table for all the game is the simplest solution.

OK, I see. To implement takeback I remember all moves since the game started (which you have to do anyway, as a hashkey alone doesn't allow you to reconstruct the position). An undo is than performed as starting a new game, and force the first N-2 or N-1 moves.

correct but when I have one table for zobrist keys the takeback is more simple because I do not need to calculate the zobrist key when I undo move and it is enough to calculate it when I make moves.

Uri