Author: Carmelo Calzerano
Date: 07:29:51 01/31/01
Go up one level in this thread
On January 31, 2001 at 09:39:10, Vincent Diepeveen wrote: >On January 31, 2001 at 08:13:52, martin fierz wrote: > >>hi, >> >>i recently corrected some code in my connect 4 program and now it is able to >>solve connect 4 in less than a day on a fast PC with a large hashtable (of >>course, connect 4 has been solved long ago). i tried again with a smaller >>hashtable and >>got some strange results, for very long searches (billions of nodes) i don't get >>the same value for >>the root position. for not-so-deep searches i get the same values for both >>versions. i am wondering, [if this is not just a bug :-)] could this be some >>hashcollision-problem? >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... 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.