Author: Robert Hyatt
Date: 20:10:40 12/13/03
Go up one level in this thread
On December 13, 2003 at 17:54:00, Uri Blass wrote: >I think about rewriting my search code and before doing it may be a good idea if >I understand somethings about the search of Crafty. > >One of the relevant files is hash.c and I think that better comments about it >are important for progress in computer chess. > >I plan to try to understand it and to give also comments. > >for now I have some questions. > >1)I see that the functions get parameters that I have as global varaibles > >int ply, int wtm > >Is there an advantage from not having them as global varaibles? 1. You can't do a parallel search with such global variables, since each thread would need a different "ply" variable. 2. It is not a good software design to depend on such global variables, when they are both input and output to a function (ie the function needs the value to do its work, and it modifies it before leaving.) That introduces what is commonly called "side effects". IE a fucntion that changes things rather than just returning a value after using the input parameters. It makes it necessary to look at every line of the function to see what it modifies, rather than just at the formal parameter list. > >I thought that asking a function to get a lot of parameters may make the program >slower so varaibles that I need in many functions like side to move are global >varaibles. In general that is correct, but for a parallel search, you can't have any tree state variables as global. > >2)I see >temp_hashkey=(wtm) ? HashKey : ~HashKey; > >My question is where exactly the program remember the hash key of previous >positions? (I guess that it needs it to detect repetitions) HashKey is a variable that is in a structure addressed by a pointer. For repetition, I add the hash key to a repetition_list[] array in the function RepetitionCheck(). > >It is possible that I do not understand the code but >it seems to me that here it does not read the hash key from an array like I do >because it has > >#define HashKey (tree->pos.hash_key) This is correct, although I do copy the existing hash key into an array for repetition checks. > >I can comment that the ~ that is used in Crafty may be better than what I do > It is just a simple way to indicate side to move. So that I won't get a hash match for right position, wrong side to move. > >I do every time that the side to move is changed > >BitBoard zob=zobkey[hply]^zobrist[0][0][0]; > >I think that it may be better and slightly faster to have >BitBoard zob=~zobkey[hply]; > >3)What is the depth that is stored in >HashStorePV? Meaningless. I simply call this before each iteration to be _sure_ that the PV moves from the previous iteration are in the table. It is possible that the original positions can be overwritten before an iteration ends, and I depend on them for proper ordering. > >storing depth 0 is logical because I guess that the pv should not be pruned >based on hash tables and you can expect depth 0 to be replaced later but I do >not see comments about the depth that is stored. > >If I understand correctly the depth is stored in draft that is 15 bits and depth >1/60 means 2^17 when depth (2^15-1)/60 that is the maximal theoretical depth >that can be stored means 2^32-2^17. Depth is stored in units of 1/60th of a ply. The field is 15 bits, which means I can store over 500 plies of depth, something I won't ever reach. :) > >Even if I understand correctly(I am not sure) >I do not understand at this moment from all the varaibles what is the depth that >is stored in the hash tables in HashStorePV. depth=0, but it is irrelevant because the type is set to WORTHLESS unless the entry exists from the real search, in which case it is left alone. Be sure you notice that this is _only_ called from Iterate(). HashStorePV() is not called inside the search at all. > >Uri
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.