Author: Robert Hyatt
Date: 10:34:34 05/07/02
Go up one level in this thread
On May 07, 2002 at 06:24:19, Uri Blass wrote: >I read in bruce moreland's site about hash tables >see http://www.seanet.com/~brucemo/topics/hashing.htm > >I try to use them first in my program only for better order of moves >and I try to use the algorithm that is in that site > >I think that there is some misleading information there > >The function RecordHash includes recording the best move but when the depth is 0 >there is no best move that was leading to the position. > >When I use hash tables only for better order of moves then it seems to be >useless to record hash tables when the remaining depth is 0. This is wrong. Depth=0 simply means you are at the frontier of the tree. You can store such position or you can not do so. It depends on whether you like one or the other better. If depth==0, I call Quiesce() and I _never_ store hash stuff in the q-search... I did at once, then tried it without doing so and found no real difference. I therefore went for simpler is better and removed storing/probing from the q-search, which does lower the "strain" on memory and table entries when searches are long and tables are small... > >I also think that recording hash tables in the last plies is relatively >unimportant at long time control and it may be even better not to try it if I >use the scheme "always replace" because it is more important to remember the >best moves in the first plies. > >Am i right? Not necessarily. Particularly if by "last few plies" you mean plies where remaining depth > 0 but less than some value N. The _next_ iteration those hash entries will still help your move ordering significantly. > >I prefer to start with something relatively simple and to check that I have no >bugs and only later to develop it to something more complicated and this is the >reason that I use "always replace" > >changing "always replace" to "only replace" when the remaining depth is big >enough seems to me simple to do when there is no problem to use information in >the hash tables about the best move for future search but replace only when the >depth is the same or bigger can cause problems later if I want to use >information of previous search about the best move because the depth in the >hashtables is wrong. > >Uri Nothing wrong with starting simple. Always store entries in the normal search, don't in the q-search. It will be easy to add it to the q-search later if you think you want to try it... A single always-replace table will not be anywhere near as good as the two-table approach most of us use (one is always replace, the other is replace with deeper draft only).
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.