Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: computer programs cannot see a very simple draw in a pawn ending

Author: Robert Hyatt

Date: 18:31:36 06/23/98

Go up one level in this thread


On June 23, 1998 at 16:18:43, Don Dailey wrote:

>On June 23, 1998 at 13:16:38, Ulrich Tuerke wrote:
>
>>On June 23, 1998 at 12:39:03, Bruce Moreland wrote:
>>
>>>
>>>On June 23, 1998 at 03:58:26, Ulrich Tuerke wrote:
>>>
>>>>I'm afraid this can imply some problems for the search. Assume
>>>>that you have flagged a position as a "draw" in your transposition
>>>>table because the 50 move rule had applied. If this position is later
>>>>reached at a lower depth via a transposition, then the hash table
>>>>would return a "draw". But may be, it really isn't because at lower
>>>>depth the search might be still below the 50 move threshold ?
>>>>This could result in real foolish moves returned from the t-table.
>>>>IMHO, similar remarks hold for the draw by repetition case.
>>>>
>>>>I think that I had once detected problems through storing these
>>>>kinds of positions in the hash table. Now, I don't store them.
>>>>
>>>>Did I get somehing wrong ?
>>>
>>>No, but you didn't get everything right, either.
>>>
>>>Draw scores don't just affect one node, they can propagate up the tree, and they
>>>can cause other nodes to have a different value, without that value necessarily
>>>being the draw score.
>>>
>>>So as long as you have a transposition table that doesn't take into account the
>>>path used to get to a node, there will always be problems.
>>>
>>>And taking into account the path used to get to a node defeats the purpose of a
>>>transposition table.
>>>
>>>So if you don't store 50-move and rep draws at the point you encounter them,
>>>maybe this will make things work better, but you can't say, "whew, it is perfect
>>>now", either.
>>
>>I know that it's not perfect. I have also taken care that a parent node of such
>>special draw node which became the current best cause of the draw evaluation
>>will not be stored either in the hash table.
>>But of course, this is still not perfect. But according to my experience it's
>>better than just to ignore the problem. I am pretty sure that in past I
>>occasionally have had serious trouble in my program resulting from 50 move rule
>>draw scores in the hash table. I am sure that the risk to obtain some
>>catastrophic move is in case of the 50 move rule is really there and may be far
>>larger than in the repetition case.
>>
>>So I changed it and it seems to work better; just a lot of pragmatism required
>>to  maintain a chess program: try and see if it's useful, nothing for theorists
>>or perfectionists.
>>
>>Anyway, thanks a lot for the feedback here.
>>
>>>
>>>bruce
>
>My solution to the 50 move draw rule as it relates to hash tables is to
>simply ignore it.  The draw position would only be solved by my program
>if it looked deep enough to see that repetition is eventually forced,
>but this probably would never happen since I don't look beyond 50
>moves of state for this.
>
>I have some doubt as to whether implementing the 50 move rule in the
>search will help in a very noticable way.  It's extremely rare that the
>program is in a 50 move situation AND a won position (which it can
>not win) simultaneously.  The 50 move rule does not even guarantee
>the win in a won situation, it just makes a win (and a loss) somewhat
>more likely.  I have seen it happen that other programs give up material
>to avoid a draw which causes it to lose.
>
>What is the general feeling on this?  Does anyone feel it adds more
>than 1 rating point to the program?  If it adds more than 1 rating
>point I might consider putting it in Cilkchess if the slowdown is
>less than 1 percent (which would approximately cancel the improvement.)
>
>I have never played a tournament game where any of my programs were
>ever in this situation and lost a half point for not getting desparate
>to avoid the draw although I realize this is always a possibility.
>I have seen it happen in test games, always on super fast levels like
>1 or 2 ply searches.  In some of these situations it was just a
>technique problem and pawn moves or captures were not involved, it
>just couldn't win knight and bishop vs king or some other difficult
>ending.
>
>Some programs use progressively higher penalties (score gets closer
>to zero) as the search proceeds without captures or pawn moves or
>castling.  I am kind of skeptical of this method too, especially
>with respect to hash tables and the tendency to play premature or
>desparate pawn moves and captures.
>
>
>- Don


it is simply a "hole" that needs filling.  Otherwise you will walk into a
draw that could be a win... and that would be unfortunate.  I didn't implement
the 50-move draw rule until I got burned several dozen times on ICC.  It wasn't
in Cray Blitz at all, and I drew a winnable game against NuChess several years
ago because Slate had it and I didn't...



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.