Author: Robert Hyatt
Date: 17:27:30 05/30/02
Go up one level in this thread
On May 30, 2002 at 20:25:43, Robert Hyatt wrote: >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... If you don't do it everywhere, you will be making many bad alpha/beta decisions. IE a bad mate score might well cause a cutoff deep in the tree that really would not happen due to the 50 move rule. You back up _that_ path to the root, with no mate score, but with the final score influenced by a wrong mate score, and you end up wrecked... > > >> >>>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.