Author: Don Dailey
Date: 13:18:43 06/23/98
Go up one level in this thread
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
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.