Author: Robert Hyatt
Date: 21:02:53 05/01/02
Go up one level in this thread
On May 01, 2002 at 21:53:01, Will Singleton wrote: >On May 01, 2002 at 11:41:54, Arwin Smit wrote: > >>Hi, >> >>I programmed a hash table for my chess engine. It seems to be faster >>and stronger now, but as far as I know the disadvantage of using a >>hashtable is that the engine will not always find the best solution >>anymore. And this is caused by not being able to see a 3-fold repetition >>draw anymore in some cases. A position may be in the hash table and >>returning a non-draw score, but it was reached in a different part of the >>search tree by repetition of positions. >> >>This worries me a bit since this is the first time I made a change to my >>engine causing it to be "non-perfect". >>Is the advantage bigger than the disadvantage? >>What is the best way to test which version is better anyway? Just let it >>play a lot of games against eachother? >> >>Arwin > >It's possible you can fix this by 1) not storing draw scores in the hash table, >and 2) testing for repetition prior to probing the hash (if you don't use the >main hash for your rep detection). There is really no way to close all the holes. It is possible that the path from the current position to the tip, which is found by a hash hit, repeats a position between the current position and the root. But it is impossible to know this without storing the complete path in a hash entry. Not storing draw scores is (IMHO) a bad idea. A draw score is as legitimate as any other score. Not storing them to avoid one problem simply creates another on the other side... And it still doesn't solve the first problem I gave, which means errors are going to occur, period... I simply ignore them... > >People have different ways of testing changes. Running the full ECM at 10, 20, >and 60 seconds is good, together with a series of at least 50 test games against >a base version of your program, or another program like GnuChess. > >If you don't see a huge difference with your new hash tables, you probably could >work on them some more. Perhaps a bug or two are present. Maybe multiple >stores/probes would help. How's your replacement scheme? Using two tables, one >depth replace and one always replace, has been shown to help. Check your >collision rate; if it's high (too many positions mapping to the same index), >then perhaps your numbers aren't random enough, or you need the multiple >store/probe approach. > >Good luck. > >Will
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.