Author: Robert Hyatt
Date: 17:25:43 05/30/02
Go up one level in this thread
On May 30, 2002 at 16:17:09, Rafael Andrist wrote: >On May 30, 2002 at 16:10:10, Robert Hyatt wrote: > >>On May 30, 2002 at 12:16:32, Rafael Andrist wrote: >> >>>On May 30, 2002 at 10:13:39, Robert Hyatt wrote: >>> >>>>On May 30, 2002 at 02:15:38, Uri Blass wrote: >>>> >>>>>On May 30, 2002 at 00:44:06, Robert Hyatt wrote: >>>>> >>>>>>On May 29, 2002 at 02:34:34, Robin Smith wrote: >>>>>> >>>>>>>The position is easily winning for white. But tablebases cause programs to want >>>>>>>to play 1.Rxf5?? after which there is a tablebase mate in 65 .... except the 50 >>>>>>>move rule kicks in first and the game ends up a draw. Are there any programs >>>>>>>that avoid this type of blunder? [D] 5k2/3K4/8/R4b2/1R6/8/3B4/5r2 w - - 0 1 >>>>>> >>>>>> >>>>>>Can't avoid it. The current tablebases don't include 50-move-rule >>>>>>issues, so this is just a fact of life for tablebases. >>>>> >>>>>You can avoid it by translating mate in 67 to something like +2 so you are going >>>>>to prefer safer ways to win the game if you can see them by search. >>>>> >>>>>Uri >>>> >>>> >>>>That won't come _close_ to fixing the problem. Suppose the alternative is >>>>+1.5, so you go for +2 and a draw? Many of these problem endings have a pawn >>>>on the board as well, which means just checking for pieces-only and saying >>>>"no mate > 50" fails on two counts: (1) there are going to be 6 piece endings >>>>that are won, even with no pawns on the board; they will be won because a >>>>piece gets won or traded prior to 50 moves passing. (2) Just because you have >>>>a pawn doesn't mean the mate in N is reachable within the 50 move rule. >>>> >>>>I don't think simple "band-aid" fixes will work. They will be wrong as often >>>>as the programs are wrong now because of the 50 move rule. >>> >>>I plan to implement the following "solution" to this problem in my program: >>>If I get a mate from EGTB and this becomes the value of the search tree, I will >>>check for captures inside the PV i.e. and, if this shows that there's a problem >>>with the 50-move rule, re-search while ignoring the EGTB hash entrys and check >>>each potentialy wrong mate distance. Of course after completing at least one ply >>>of normal search without questioning the EGTB. >>> >>>Rafael B. Andrist >> >> >>How does that solve the problem? You might be diving into a KNN vs KP >>ending that you can win, but not within 50 moves. Or you might be able >>to win it within the 50 move rule limit by capturing the pawn "just in >>time" or making the opponent move the opponent at an opportune time to >>reset the counter. > >After getting a possibly wrong mate from EGTB (backed up to the root of the >search tree) you trace the PV and check if [remaining moves to 50-move rule] <= >[mate distance]. As long as this is not true, you extend subtrees along the >EGTB-PV untill you find an ok mate or you return a draw score. If you run out of >time during this process, you decide to trust the EGTB. You loose nothing, you >can only win. This would kill performance. Because you can't wait until you back the score up to the root, because _every_ move might fail in the same way. You would really need to do this any time you get an EGTB hit anywhere within the tree. And that would crush the performance... > >>I don't see how to fix this without more information in the tables. > >It's clear that the only clean solution would be combined DTM and DTZ tables. > >regards >Rafael B. Andrist There we agree. It has to happen sometime.
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.