Author: Tony Werten
Date: 02:57:58 02/01/01
Go up one level in this thread
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? can anybody give me a probability for a hash collision >occuring when using B-byte key & lock, with a hashtable with S entries after >searching N nodes? (i am using 4 byte ints for the key and the lock) >also, i think i remember somebody mentioning here that one can choose the random >numbers for the XORs in a clever way making hashcollision probabilities >smaller - can somebody tell me how? Ideal would be if every number would change half of the number of bits. Currently I'm working on connect 4,5,6 and 7, using hash scheme of 64bits. I have found no problems. The advantage of using zobrist is you can handle mirroring very easy. You just have to keep 16 hash values and store the lowest. It sounds slow, but getting a hashhit saves such a lot of nodes that it's worth it. Using this hashscheme and some intelligent recognisers (recognizing win-in-5-moves is a big winner), solving 4 in a row shouldn't cost you more than 2M nodes (with boards >= 6 by 5, wich is the minimum size for a first player win). BTW make sure you include side-to-move in the hashvalue. cheers, Tony > >cheers > martin
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.