by crystalclear » 14 Dec 2012, 02:01
Perhaps I should explain myself a little. I am looking at this in relation to implementing repetition detection in my program.
I have some repetition detection software and it seems to detect when a position is repeated during the search and if it finds a repeat, it returns zero. Nevertheless, my program - for reasons I don't understand - will too often draw a game by repetition when it is ahead by a significant margin.
I can understand it happening sometimes, for example if it has a large material advantage but spots a mate threat against the program and repetition is the only way to avoid teh checkmate. But it seems to happen too often and in situations where there is no obvious need for repetition. So I looked at the rules for guidance, and I am a little confused by the text about a temporary change in castling rights. In my terminology, castling rights can only be lost and never gained: if you temporarily cannot castle because you are in check, would castle through check, or into check, or if a square between king and rook is occupied, I don't call that as a loss of castling rights. I refer to it as inability to castle despite possibly having castling rights.
Now if you are unable to castle, my thinking is that you will also be unable to castle in similar looking positions: same pieces on same squares.
=
I am uncomfortable with the whole scenario of position repetition in chess programs.
It seems to me that there is nothing in the UCI specification to handle claiming a draw by repetition.
At least one GUI seems to think that a game is drawn if the same position occurs three times. However the FIDE rules are that my program should be able to claim a draw (for example if the score is negative five pawns and the game looks lost) or not claim a draw (for example if deeper search has begun to reveal a promising looking move that had previously not looked so good and the score is now positive five pawns).
Another thing that makes me uncomfortable with draw-by-repetition is an article I read on graph history interaction, which makes me worry whether draw scores propagated up through the search function should be stored in the transposition tables conditionally or unconditionally and what search depth I should store.
If a position has occurred twice in a game, with the opponent to move, then when my search encounters the position it would be the third occurence in the game and the opponent should have the option of claiming a draw. So if things worked properly my program would be treating the possibility of a draw claim by somehow putting a lower bound of zero on the position's score and searching further to see what could happen from there.
What I think would happen in practice is that my program as it is now would recognize the repeated position and just score it as zero without further investigation.
If the position then arose in the game, the GUI would gazump my opponent and stop the game and report it as a draw, even if the opponent wanted to play on.
Everything seems wrong:
my program cannot claim a draw,
my program treats repetition as zero rather than a lower bound,
the GUI assumes draws on repetition,
my program reacts to the second occurence of a position and not really the third.
Reacting to the second occurence is maybe a good thing to do in a search, but in the rules, it is the third occurence that is important. I guess that needs some sort of careful coding. I have seen one very good chess engine - stockfish, Houdini, or something similar - that couldn't find a good move which existed because it required the game to pass through a position that had already occurred. It must have been scoring the position as zero each time it encountered it, and it was incapable of seeing a win which required the game to pass through a previous position and play a winning move instead of a drawing move that had been played earlier in the game.
=
One last note on repetition.
I saw a game played in Gibraltar 2012 where an English player called Howell could draw the game by repetition quite easily, but he was playing for a win.
He would play from a position and manouver himself into a second repetition of that position. Then he advanced the game a little and repeated that new position.
The process allowed him to increase the number of moves in the game and thus reach a time control point without running into time control problems.
I remember thinking to myself that there probably isn't a single computer chess program in existence that could have played like that.
Humans seem to sometimes use a first repetition to test whether their opponent is happy with a draw. It could be that deviation from the repetition moves by the opponent gives you a bigger advantage than deviating yourself. So even if you don't want a position to occur three times, it can be worthwhile having it occur twice.
