Author: J. Wesley Cleveland
Date: 14:19:33 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. > >>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. An idea I had is to set a bit in (or add, say 1024 to) the value of each won or lost position that does not convert in 50 moves. I think this could easily be done when generating the tables, and compression would remove most of the overhead.
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.