Author: Pham Hong Nguyen
Date: 18:53:56 06/24/02
Go up one level in this thread
On June 24, 2002 at 11:12:37, Robert Hyatt wrote:
>On June 24, 2002 at 00:01:23, Pham Hong Nguyen wrote:
>
>>>First, you probably don't want the king positions hashed into your pawn
>>>structure hash signature.
>>>
>>>Second, all you can really hash is simple pawn structure information, plus
>>>information that is expensive to compute (where are passed pawns, weak pawns,
>>>and the like) so that you can use this elsewhere without having to compute it,
>>>when you get a pawn hash hit...
>>
>>I think I had had wrong understanding about the content of pawn's hash table.
>>Thanks for your exlaination. Some other questions:
>>- How many bits do you use for that simple structure? (and what are they?)
>
>
>
>I store the following:
>typedef struct {
> BITBOARD key;
> short p_score;
>
> unsigned char allb;
> unsigned char black_defects_k;
> unsigned char black_defects_q;
> unsigned char passed_b;
> unsigned char candidates_b;
>
> unsigned char allw;
> unsigned char white_defects_k;
> unsigned char white_defects_q;
> unsigned char passed_w;
> unsigned char candidates_w;
>
> unsigned char protected;
> unsigned char outside;
> unsigned char open_files;
>} PAWN_HASH_ENTRY;
>
>There are five values for black and five for white.
>
>allb/w is an 8 bit mask, 1 bit per file, saying "there is a white or black
>pawn on this file."
>
>defects K/Q indicates the "pawn structure related 'defects'" for the kingside
>and queenside pawns (used after determining which side the king is on after
>castling.
>
>passed is passed pawns, 1 bit per file, saying "the most advanced pawn on this
>file is passed"
>
>candidates is the same thing but for "candidate passers". IE black has a pawn
>at a7, none on b or c files. White has pawns at a2 and b2. White has a
>candidate passer on the b file.
>
>the final 3 values include which side has a protected passed pawn on which file,
>which side has an "outside passer" on which file
>
>And finally which files are open, period.
Thanks Bob, I got it.
>
>
>>- Do you know how fast of that method (use hash table for simple pawn structure)
>>is, comparing with method of updating pawn structure on the fly?
>>
>>Many thanks,
>>PHN
>
>It costs nothing, basically, to "hash". This means that whatever you do
>in EvaluatePawns() will be free since you will compute it once and use it
>every time you reach the same position.
>
I am still worrying about that point: we should maintain hash key, check and
extract data from pawn hash table for every call of eval, make some extra
computing to add more information for pawn structure (because simple structure
may lack some usefull information). On other hand, if I maintain pawn structure
on the fly (my currrent method), I may pay little more when updating a pawn
move, but it will cost _real_ nothing for every call of eval.
In one testing version of my engine, I implemented pawn hash table which returns
score (not structure) of pawns. It should save more than one which returns
structure. However, it saves around 5-7% of time and just little faster my
currrent way.
BTW, I will implement pawn hash table as your suggested structure, compare with
my current way and report the result when it is available (not soon ;) ).
Thanks again.
Regards,
PHN
>
>
>>
>>
>>>
>>>Note that the score you hash can _only_ depend on the positions of pawns. If
>>>you do _anything_ else you will introduce a bug, since the signature will not
>>>reflect the locations of anything but pawns...
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.