Author: Martin Giepmans
Date: 13:43:39 08/08/01
Go up one level in this thread
On August 08, 2001 at 14:23:34, Bruce Moreland wrote: >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 Yes, I see your point. Now the question is: is there always pollution? I think 2 conditions are necessary: (1) The score (+0.20) is influenced by a drawscore that is based on *external* repetition. (There is no problem with the influence of internal repetition) (2) The influenced score is stored in the hashtable and used in the next calculation, after the opponent has moved. (There is no problem if the scores are used in this calculation) Proposition: Cutting off based on "old" hashtable scores is nonsense. Rip it out! :) (I did) Martin
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.