Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: programmers: pawn hash tables

Author: Robert Hyatt

Date: 06:47:05 03/08/03

Go up one level in this thread


On March 08, 2003 at 03:17:19, Uri Blass wrote:

>On March 08, 2003 at 01:42:15, Robert Hyatt wrote:
>
>>On March 08, 2003 at 01:29:46, Joel wrote:
>>
>>>Hey All,
>>>
>>>Just wondering what everyone thinks is the best way to implement a pawn hash
>>>table?
>>>
>>>At the moment I am incrementally generating a seperate pair of pawn hash keys,
>>>and using them to index a table - very similar to how my transposition table
>>>works.
>>>
>>>Is it possible to do _significantly_ better than this? It seems to be somewhat
>>>expensive to do, although having said that my NPS still went up at least 20% in
>>>most situations.
>>
>>That is what everyone since chess 4.x has done.  Two signatures, one for
>>all pieces and pawns, one just for pawns.
>>
>
>Not everyone.

I should have said "everyone that does pawn hashing does it the way you are
doing it..."


>There are a lot of programs without pawn hash tables and there are even a lot of
>chess programs without hash tables.


Not "real" programs I bet.  Hashing provides way too much of an advantage to
never do it.



>
>I remember that I found something like 10% speed reduction in nps from adding
>bitboards for passed pawns,isolated pawns and protected passed pawns by pawns
>and I earned more than it in speed from other changes.
>
>I still do not evaluate passed pawns when they are not protected by a pawn and I
>think that the question how to evaluate passed pawns relative to the kings and
>other things is more important than pawn hash tables(Maybe it is good to give
>some small static bonus for passed pawns but I did not like this idea because I
>know that there are cases when passed pawns are trapped and these cases are not
>rare).
>
>Another point is to evaluate king relative to pawns and not only passed pawns
>because one of the problems of movei in endgames is that it always assumes  that
>the best place for the king is the centre and it may be a problem also in case
>when there are no passed pawns.

I do that and it doesn't interfere with pawn hashing at all.

>
> >
>>
>>
>>
>>>
>>>I am not really worried about effeciency as much as some other people here, so I
>>>guess I am really asking whether I am missing something major.
>>
>>Doesn't sound like it.  But you will end up storing more than just a score for
>>the position.  IE passed pawn locations, weak pawn locations (or bitmaps that
>>feature them).  Etc...
>
>How many bits do you need to do it?

8 bits per feature per side.  Passed pawns are flagged with a "1" on the file
they stand on.  Weak pawns the same.  Open files the same.  Etc.  My pawn hash
table entry is 19 bytes, you can see what's in there in "chess.h".



>The simplest way that I think about asks for 192 bits for that information when
>usually most of them are 0's(maybe it is not very important because even with
>small number of hash entries you have not a lot of pawn structures).
>
>There can be in theory 8 passed pawns for white or 8 passed pawns for black
>If you want to store every square then you need 6 bits for every square so
>you need 6*8 bits only for white passed pawns and 6*8 bits for black passed
>pawns.

don't need the square, just need the file.  The pawn is trivial to find with
bitmaps.

>
>If the same is for weak pawns you get 192 bits in your hash tables for pawns.
>

No.  16 bits for files that contain white/black passed pawns.  16 bits for
white/black weak pawns.  Etc.



>Uri
>
>>
>>>
>>>Regards,
>>>Joel



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.