Author: Bruce Moreland
Date: 11:23:34 08/08/01
Go up one level in this thread
On August 08, 2001 at 13:56:05, Martin Giepmans wrote: >On August 08, 2001 at 13:22:03, Bruce Moreland wrote: > >>On August 08, 2001 at 12:30:47, TEERAPONG TOVIRAT wrote: >> >>> >>>Hi, >>> >>>As I understand, a draw score from hashtable can be originated from >>>1.an almost equal position 2.repetition of position >>>Is it generally recommended to differentiate these 2 conditions? >>>How much would I gain if I fix the problem? >> >>Rip out your hash table stuff, or at very least don't cut off based upon hash >>table score. >> >>This is probably a bit too harsh, so another possibility is to ignore the >>problem. >> >>It's not just the draw score, it's any score. If you never ever hash 0.00 or >>cut off based upon 0.00 in the table, you will *still* have problems. >> >>Let's say you have to choose between two positions. Position A is +0.40. >>Position B is +0.20. >> >>If you detect a repetition on A, your score for this search will be +0.20. If >>you detect one on B, your score is +0.20. >> >>Neither of those is 0.00, but if you encounter this position when there is a >>change in which move (if any) leads to a rep, you'll get an erroneous score. >>You could return +0.20 when move A doesn't lead to a rep, and you could return >>+0.40 when it does. >> >>So the bottom line is you are screwed no matter what. >> >>bruce >> > >I don't understand this. In the circumstances that you describe position A and B >will in my program both get E = 0.00. How could they get E = +0.20? >And because the program never uses a drawscore from the hashtable for a cutoff >(because it cannot know if this score is based on a repetition or not) there is >no problem. True? I choose A. I execute the move. I recurse. The position is determined to be a repetition, and 0.00 is returned. I get the zero back and that becomes my best choice. I choose B now. I execute the move and recurse. It's not a repetition, so I do my search and it comes back 0.20. That's better than 0.00 so that's now my best move, and I'll return +0.20 at the end of this. This +0.20 goes into the hash table. It is not a 0.00, so you can't detect that the score may be polluted because it's the draw score. However, it has been significantly *influenced* by a draw score elsewhere in the tree. My most significant point here is that once you start scoring paths (a repetition is a score based upon path taken to the position, not the position itself), you introduce problems if you store *positions* and not *paths*. I don't think it's possible to be rid of this problem without throwing away significant benefits of using a hash table. Cutting off based upon hash table scores is not strictly correct, and there will always be problems. The problems will manifest as search instability. If you fail-high and re-search, you may fail low on the re-search. bruce
This page took 0.01 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.