Author: blass uri
Date: 23:02:34 03/08/00
Go up one level in this thread
On March 08, 2000 at 23:47:32, Robert Hyatt wrote: >On March 08, 2000 at 09:41:05, blass uri wrote: > >>On March 08, 2000 at 07:23:47, José Carlos wrote: >> >>>On March 08, 2000 at 06:29:13, blass uri 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? >>>> >>>>I believe that many programs falls into this trap because they evaluate second >>>>repetition as a draw. >>>> >>>>It is usually not important against computers because computers do not do >>>>tactical blunders but it may be important against humans. >>>> >>>>The reason that programs do it is that most of the programs were not designed in >>>>the right way. >>> >>> I disagree. I think that is the right way of doing things. Programs (including >>>mine) test for second repetition assuming both sides played the best moves they >>>found. Testing third repetition instead of second takes way longer, and you need >>>two extra plies to find it. >>> You can choose testing third instead of second, it is not any difficult to >>>implement, but there will be very few cases where this will help, and a lot of >>>cases where this will slow down the search: more time for the test, more plies >>>to find it and you cannot return the draw value in second, so you have to >>>generate many more nodes. >>> >>> Just my opinion, anyway. >>> >>> José C. >> >>I do not suggest to test for third repetition but only to ignore previous >>positions in the test for second repetition (with the exception of cases when >>there was a repetition of previous positions). >> >>I do not think that it is going to slow down the search significantly because I >>believe that most of the repetition in the search are repetitions of positions >>that were not in the game. >> >>Uri > > >This is probably wrong. ie I play Ng1-f3 on the board. The next move I >might try is Nf3-g1. That is a repetition. That you won't treat as a >repetition. This happens more than a few times in the search... Searching >below Nf3-g1 until I play Ng1-f3 again takes some work that could be avoided >here, leaving open the hole already mentioned... There is a simple experiment that it is possible to do. try to analyze position with no game before it and with game before it. If there was no repetition in the game(this is the usual case) then the idea that ferret is using is the same as ignoring the game history. It is possible to check how much you are slower by ignoring the game history. I guess that in most of the cases the slow down is less than 1% Uri
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.