Author: Eugene Nalimov
Date: 09:52:23 10/08/99
Go up one level in this thread
I think there is a simple solution: from the search() function return not only the score, but also a flag "path information was used". That flag should be set if (1) draw by repetition was detected, (2) 50 moves rule was used, (3) any of the searched children of the node returned that flag. Before storing to the hash table, check that flag, and if it's set, do not store the score, store only the best move. I am not sure the overhead of the solution is tolerable, and maybe it's better just to ignore the problem, but I think the proposed solution will cure the problem once and for all. Eugene On October 08, 1999 at 12:13:07, Bruce Moreland wrote: >On October 08, 1999 at 04:13:10, Inmann Werner wrote: > >>On October 07, 1999 at 23:40:21, Bruce Moreland wrote: >> >>>On October 07, 1999 at 20:45:08, James Robertson wrote: >>> >>>>My search currently decides a position is drawn if it has repeated twice. I >>>>think this is causing my search to sometimes stuff 2nd rep draw values into the >>>>hash table that can be retrieved for positions with different history's. Is this >>>>a problem? What do other people do? Could I just not store any draw values in >>>>the hash table? Should I go to draw by 3rd rep? >>> >>>Don't store it, since it can only cause problems if you do. >>> >>>But your problems won't end if you don't store these scores, since a large >>>portion of the tree can potentially be affected by the presence of repetitions. >>> >>>The bottom line is that you can't completely solve this problem. What will >>>happen is that when you re-search a position that failed high, it might fail >>>low, which you'd think should be impossible. You can't fix this, all you can do >>>is come up with a way not to explode when it happens. >>> >>>bruce >> >>Nice description :) >>I exploded more than one time. >>I have one line in my code to avoid storing repetition code or allow it, and >>depending on my "explodes" I change them. It is really ugly. Not storing causes >>problems, all getting slow, storing sometimes produces trash... >>If I store it, my program gets better in getting draws in "lost positions" but >>looses games at other times... GRRR! >> >> >>I tried some thing, which is not bad, but ugly. I give draw by repetition a >>"special value" and store it to hashtables for sorting. If I disable "storing" I >>do not loose the move ordering, but it is also ugly, cause it does not work >>really (clear why?). >> >>It is all GRRR! >> >>Werner > >At the point you decide you have a rep, you will probably be in a different >place than you are when you fail high or return alpha at the end. There might >be a call to a hash table store function there. It doesn't hurt to take that >out, since the value stored will be more or less wrong. > >You can't fix the problem, because the existence of these draw scores affects >the values of other nodes, without necessarily causing them to get the draw >score. You might have two moves in position A, one of which should get a score >of 35, the other should get a score of 20. But the one that gets a 35 is a rep, >so that's zero, so position A is scored as 20. > >Maybe you encounter position A some other time, when neither of these moves is a >repetition. In this case, you have 20 in the hash table, but if you searched >all of the moves you'd get a score of 35. > >In my opinion it is best to ignore this problem entirely. Just don't store the >draw score when you first encounter it, but ignore it otherwise. > >The conventional wisdom on hashing is that it is easy to implement but extremely >hard to debug. I don't know how fresh your program is, but if you are having >weird hashing problems they could be due to other hashing bugs. > >bruce
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.