Author: Robert Hyatt
Date: 13:09:56 09/16/99
Go up one level in this thread
On September 16, 1999 at 12:07:27, Tom Kerrigan wrote: >What if it was 32 and 32 then? > >And remember, with this setup, it's not like the "main" hash key is any shorter. >It's just divided into two parts. > >-Tom It is worth trying, but do it on a fast machine so the trees are big. My concern is that your hashing becomes 32 bits wide effectively, in positions like fine 70 or any king and pawn ending. That seems to be asking for trouble, but that is just a gut feeling without any testing of any sort... > >On September 16, 1999 at 09:44:56, Robert Hyatt wrote: > >>On September 16, 1999 at 04:00:43, Tom Kerrigan wrote: >> >>>If you have a program with 64 bit hash keys, is it a good idea to devote n bits >>>to pawns and the rest to pieces and side-to-move? >>> >>>I was thinking a good balance may be 24 bits for pawns, but I have no data to >>>back this up. Does anybody else? >>> >>>-Tom >> >>If you are going to use them independently to probe tables (ie using the 24 >>bits to probe the pawn hash table) then this won't work well. 24 bits is only >>16 million possibilities... that will get more than a few collisions. And >>the same for the upper 40 bits and pieces. I know that 32 bits is not enough >>for normal hashing. Stanback/I ran a bunch of tests years ago in a discussion >>on r.g.c.c and we got collisions by the bucketload with 32 bit keys. 64 was >>totally safe back then, although speeds are way up now compared to then. I >>am using a 32 bit pawn hash signature, but a full 64 bit total hash signature.
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.