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.