Page 2 of 2
Re: bugs in hash tables
Posted: Sun Aug 12, 2007 7:10 pm
by Michael Sherwin
PK-4 wrote: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.
Re: bugs in hash tables
Posted: Sun Aug 12, 2007 8:35 pm
by hgm
Uri Blass wrote: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.
Re: bugs in hash tables
Posted: Sun Aug 12, 2007 9:37 pm
by Uri Blass
hgm wrote:Uri Blass wrote: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