Author: Carmelo Calzerano
Date: 07:53:11 01/31/01
Go up one level in this thread
On January 31, 2001 at 10:43:41, martin fierz wrote: >On January 31, 2001 at 10:29:51, Carmelo Calzerano wrote: > >>>You're using 32 bits to hash? >>> >>>I think there are like 7x6 rows or so = 2^42 possibilities which you >>>hash in 32 bits. >>> >>>Easier is to store the entire position. This fits easily in 64 bits >>>as with are 7 rows (?) at most 7 open spots are there. >>>you can do next: white = 0, black = 1. >>>open spots also 0. >>>Now also describe how far each row is open. That's 3 bits for 7 rows = 21 >>>bits. >>>So in 42 + 21 bits you can store the entire position. That's not hashing >>>but a true hash. >>>For solving a game you definitely need to store the entire position! >>>With just 32 bits you ask for trouble! >> >>Vincent, >>which kind of indexing scheme would be suitable for such a table?! >>Whichever you use, you are mapping similar positions in the same entry: >>you'll get killed by conflicts, unless you plan to use a 2^64 entries table >>of course... >> >nobody dies here... you can use any normal indexing scheme, as long as you save >a unique hashlock-code in the table you are safe. you can still get two >positions indexed the same way, but you will detect it. But it's not a matter of safety, it's a matter of performance: lots of positions in big subtrees will map in just a bunch of hash entries. You will be able to easily detect all these conflicts, just comparing the full hash keys; but the hash table will be almost useless... Bye, Carmelo
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.