Author: Dan Newman
Date: 00:45:23 10/26/99
Go up one level in this thread
On October 25, 1999 at 14:59:21, William Bryant wrote: >Since pawn evaluations are static, ie this pawn formation gives this score, >the amount of information stored in a pawn hash table should be really simple. > >I was thinking of using a simple long long value. > >This gives 64 bits. >Index the bottom 19 bits (that indexes 262144 positions for a table size of > 2M)into the table >Store the hash signature (64 bits) minus the bottom 16 bits for the score. >Between the index and stored score that gives an overlap of 3 bits. > >This should prevent matching errors and keep the record size low. > >Is there any information I'll need that I'm leaving out. > >Thanks in advance. > >William >wbryant@ix.netcom.com I have yet to put a pawn hash table in my program, but as I understand it, you'll probably want to store more there than a single score for the pawn structure. The idea is to save on expensive eval calculations involving pawns, so you can store things like a pair of 8-bit bitmaps that indicate which files have passed pawns (one for each color), pawn shelter info for both king-side and queen-side, and so forth. Then when you go to calculate (for instance) king safety, you can select the appropriate shelter info to use (depending on which side the king has castled to). What you store in the table must be calculated only from the conformation of pawns and nothing else since that is what is used to calculate the hashcode. But, there are interactions between other pieces and the pawn structure that are important. So what you can do is store partially completed calculations involving only the pawns into this table and then look up this information and complete the calculation when you do your eval. -Dan.
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.