Author: Bruce Moreland
Date: 17:14:31 03/08/00
Go up one level in this thread
On March 08, 2000 at 11:27:14, Andreas Stabel wrote: >On March 08, 2000 at 08:34:45, Robert Hyatt wrote: > >>On March 08, 2000 at 05:11:11, Howard Exner wrote: >> >>>Test your chess engine if it handles this repition theme correctly. To do this >>>set up the position below and play the white side yourself. Do not enter the >>>winning move Kh5 but instead play the blunder Kg5. Now let your program play the >>>black side at say game/15. It will of course play Kd5+ which forces perpetual >>>check. After it does that try to trick the program and reply Kg4. >>>Now the test - does your program play the correct Qd1+ or does it blunder and >>>mistakenly repeat the position with Qe4+, assuming that the opponent will >>>blunder again with Kg5? Rebel Century failed this test and assumed white would >>>play again the poor move Kg5. >>>Why would a program do this? Do other programs fall into this trap of assuming >>>a repetition of moves even when not forced? >>> >>>[D]8/4k3/7Q/8/4q1KP/6P1/8/8 w - - >> >>This is a known problem. Most count 2-fold repetition as draw, as if the >>2-fold repetition can be forced with best play, the 3-fold repetition can also >>be forced. In this case it is wrong, but generally it works fine. >> >>fixing this is easy, but the fix is far worse than the problem. Because to >>require the search to see a 3-fold repetition to recognize a draw would make >>most draws too deep to see. > >There is perhaps an in between solution. Not to put moves already done into >the hash table, so only positions encountered twice in the same path in the >actual search is counted as a draw. Of course this has to go together with >a check in the root if any of the legal moves leads to a third repeat. I have been doing this for years. When I start my search, there is a list of positions that I can't repeat without returning contempt factor. Before, this list was the whole game, back to the previous reversible move. Now, it's just those positions that have already occurred twice. It was a very simple change. >The problem above is very visible when I analyze a match between two GMs, and >one has a big advantage, tries a move which gives to other the chance to go >back to a previous position, and now crafty thinks it is a draw ! Yes, that's the annoying but not fatal problem. The fatal problems are: 1) When you can choose between entering a lost variation for the second time, and taking a real draw, and make the wrong choice. This problem theoretically costs you a half point. It's likely to come up most against humans who are having a hard time figuring out how to beat you, but it can happen against computers that are blundering around trying to make progress, if they don't have anything in them that prevents them from taking a second repetition. 2) The case from one of my program's first games on ICC. It was down two pawns, and found a shot that won a pawn. The opponent's best reply was to undo his previous move and let me take the pawn, so he did that. By my program undid the shot, allowing the opponent to remain two pawns up. This problem could very easily cost a half point or even more, if you could have gone from a dead lost position to one where you are slightly down but have tons of counterplay. bruce
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.