I have finally gotten around to implementing repetition detection (I scan a combination of the tree stack and game history for matching hash keys) - and it is fast and works great. I treat all threefold repetitions as draws.
Questions:
(1) sometimes my engine is happy to repeat a position, but not a third time. This is annoying, and loses time, and risks hitting the 50 move rule unnecessarily prematurely. However, the solution of telling the engine to believe a 2fold repetition (presumably twice in tree stack / 0 in game tree, or once in tree stack and once in game history) is a draw seems very dangerous to me - precisely because it isn't really a draw, it could cause bad moves. But which is worse? My limited chess experience is making this a hard decision. Is there consensus on this? Is there some other solution that is cleaner or devoid of problems?
(2) the need to scan for repetition can stop at a pawn move or capture. Obviously, it could at castling, too, since that's an irrevocable change to the board. Right? And why do all definitions of the 50 move rule omit any mention of castling?
(3) as for contempt factor, I was thinking of assigning all draws (including stalemate) a score of -25 if it's the computer's turn (1/4 pawn), and a score of 0 if it's the human's turn. Does anyone see any problems with this?
questions on rep detection
Moderator: Ras
-
- Posts: 3562
- Joined: Thu Mar 09, 2006 3:54 am
- Location: San Jose, California
Re: questions on rep detection
A very old trick that I used years ago was to give my program a penalty if it moved back to the same square that it had just come from. This is far from perfect but if the penalty is big enough you never have to worry about there move repetition.
-
- Posts: 838
- Joined: Thu Jul 05, 2007 5:03 pm
- Location: British Columbia, Canada
Re: questions on rep detection
Did the program also apply this scoring penalty to the opponent? Could that make it think the repetition was undesirable, when the opponent might actually want to do it?Bill Rogers wrote:A very old trick that I used years ago was to give my program a penalty if it moved back to the same square that it had just come from. This is far from perfect but if the penalty is big enough you never have to worry about there move repetition.
Re: questions on rep detection
1) if you need a position to repeat 3 times then you won't detect a lot of repetitions in your search (because you need to look a lot deeper to see them). Bad idea imo, there is no more risk in pretending that there is a real draw (after the first repetition) than there is risk in any evaluation (i mean your eval is allways wrong anyway). Trying to draw in a bad position is never bad, if your engine finds a pseudo draw by repetition that means that your opponent could not find a better line (ie the line is forced or your evaluation is the opponent position is flawed).
2) castle has 'in practice' no influence on the 50 moves rule, so i think ppl just forgot to code that rule. Note that some engines handle that correctly.
HJ.
2) castle has 'in practice' no influence on the 50 moves rule, so i think ppl just forgot to code that rule. Note that some engines handle that correctly.
HJ.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: questions on rep detection
The only way it could cause a "bad" move is the following:AndrewShort wrote:I have finally gotten around to implementing repetition detection (I scan a combination of the tree stack and game history for matching hash keys) - and it is fast and works great. I treat all threefold repetitions as draws.
Questions:
(1) sometimes my engine is happy to repeat a position, but not a third time. This is annoying, and loses time, and risks hitting the 50 move rule unnecessarily prematurely. However, the solution of telling the engine to believe a 2fold repetition (presumably twice in tree stack / 0 in game tree, or once in tree stack and once in game history) is a draw seems very dangerous to me - precisely because it isn't really a draw, it could cause bad moves. But which is worse? My limited chess experience is making this a hard decision. Is there consensus on this? Is there some other solution that is cleaner or devoid of problems?
You reach the position for the first time, and then continue playing. For some unknown reason, your opponent plays a bad move along the way and you reach the position for the second time. You play the move leading to the second repetition, thinking it is a draw, but your opponent now corrects his bad move and goes on to win. How likely is that? Near zero. And, when you think about it, you were lost until he made the wrong move the first time anyway, so why does it matter?
3-fold will hide _most_ repetitions from your search. You will see the two-fold repetitions easier, but if you don't count them as draws, you will continue to think you are winning or losing, erroneously, and miss a chance for a better result.
It's just the way it is defined. "it is what it is". In general, it is irrelevant anyway as repetitions where one side can castle are _very_ uncommon when you think about it...
(2) the need to scan for repetition can stop at a pawn move or capture. Obviously, it could at castling, too, since that's an irrevocable change to the board. Right? And why do all definitions of the 50 move rule omit any mention of castling?
It will introduce a search instability of sorts. Why isn't a draw a draw, regardless of which side is on move? I adjust Crafty's contempt factor automatically depending on its rating and the rating of the opponent.
(3) as for contempt factor, I was thinking of assigning all draws (including stalemate) a score of -25 if it's the computer's turn (1/4 pawn), and a score of 0 if it's the human's turn. Does anyone see any problems with this?
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: questions on rep detection
Correct. I include the castle status in the hash signature, so Crafty is aware of the ability (or lack) of castling rights, which will correctly handle repetitions and 50-move draws. I assumed everyone does this else they have a hash bug that will hurt in some positions where you think a position where you can't castle is identical with a position where you could, and you use that wrong score in the tree.Harald Johnsen wrote:1) if you need a position to repeat 3 times then you won't detect a lot of repetitions in your search (because you need to look a lot deeper to see them). Bad idea imo, there is no more risk in pretending that there is a real draw (after the first repetition) than there is risk in any evaluation (i mean your eval is allways wrong anyway). Trying to draw in a bad position is never bad, if your engine finds a pseudo draw by repetition that means that your opponent could not find a better line (ie the line is forced or your evaluation is the opponent position is flawed).
2) castle has 'in practice' no influence on the 50 moves rule, so i think ppl just forgot to code that rule. Note that some engines handle that correctly.
HJ.
Re: questions on rep detection
Thanks- that all makes sense. You guys are so helpful