Author: Robert Hyatt
Date: 11:49:17 01/12/98
Go up one level in this thread
On January 12, 1998 at 14:23:02, Dan Homan wrote: >This discussion has made me wonder if my pawn hash table is >really effective. If it is not, I probably have a bug either >in my understanding or in my implementation. To check, I >thought I would output the search results from my program on >WAC 003. > >Some notes first: > hash table size: 262144 entries, 6291456 bytes > pawn hash table size: 65536 entries, 1048576 bytes > >My pawn hash table also uses the position of the king >(as well as the pawns) to compute the pawn hash code. this definitely hurts. IE for every pawn position, there are 4096 ways it can be stored, thanks to the two kings that can be anywhere on the board. here's one quick trick (I assume you factor in the kings so you can do king safety evaluation of the pawns?) If so, I did that in Cray Blitz, and early versions of Crafty. I later went to a simpler approach that simply evaluates the king-side pawn king-safety defects and the queen-side pawn king-safety defects, and stores these in the pawn hash structure. I then choose the king-side, queen-side or central pawn king safety defect count depending on where the king is. > >Test Position: WAC 003 > > +---+---+---+---+---+---+---+---+ >8 | | | | | | *R| *K| | White to move > +---+---+---+---+---+---+---+---+ >7 | | *P| *P| *B| | | | *P| castle: - > +---+---+---+---+---+---+---+---+ >6 | *P| | *P| *B| | | | | > +---+---+---+---+---+---+---+---+ >5 | | | | | | | *Q| | > +---+---+---+---+---+---+---+---+ >4 | | | | P | | *P| | *R| fifty: 0 > +---+---+---+---+---+---+---+---+ >3 | | | P | | R | | | P | > +---+---+---+---+---+---+---+---+ >2 | P | P | | B | Q | | P | | > +---+---+---+---+---+---+---+---+ >1 | | | | | | R | K | N | > +---+---+---+---+---+---+---+---+ > a b c d e f g h > > >White to Move Book Move: Rg3; > >Press 's' to search, 'n' for the next position, 'q' to exit: s >Please enter a search time (in seconds): 30 > 3. 154 0 1300 e3g3 g5g3 h1g3 > 4. 313 0 5297 e3g3 d7g4 g3g4 > 5. 313 0 10408 e3g3 d7g4 g3g4 > 6. 313 2 53982 e3g3 d7g4 g3g4 > 7. 313 5 174534 e3g3 d7g4 g3g4 > 8. 313 20 735301 e3g3 d7g4 g3g4 h4g4 e2e6 g8h8 > h3g4 g5f6 f1e1 f4f3 > >node_count = 885911 quiescent nodes = 82048 eval_count = 183571 >hash hits = 74864 hash moves = 9095 pawn hash hits = 173696 >node_rate = 36912 null cutoffs = 167276 extensions = 15099 > I tried this to a depth of 8 plies (which I assume the above means you reached?) Total time was 2 seconds, with a hash hit rate of 99%. I re-ran it to 30 seconds and was able to search 11 plies deep this time, and the pawn hash hit rate was still 99%. I used 5mb for the pawn hash, where one entry is 20 bytes. >Searched Move: Re3-g3 Book Move: Rg3 > >So my pawn hash is 95% effective. This is an average to good >position. In positions where the king can move a lot, the >percentage can be as low as 80%. Is hashing in the king >position a good idea? I do it to keep avoid having to >recalculate some king safety infomation. try what I do. Compute it for the possible king positions (kingside, q-side or center) and store each count. Then look up that number and do only minor king-safety stuff for each piece based on the condition of the pawns around the king. If you get your hit rate to 99% as mine is, *anything* you do in pawn scoring can basically be ignored, as it won't slow you down by any measurable amount. > >(Note: Quiescent nodes seems low because I don't count the > entry into the quiescent search as a quiescent node. > Such a node (usually at depth = 0) is counted as a > full width node only. ) > > - Dan
This page took 0.02 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.