Author: Carmelo Calzerano
Date: 07:45:40 02/08/01
Go up one level in this thread
On February 08, 2001 at 10:25:22, Rafael Andrist wrote: >On February 07, 2001 at 11:31:12, Robert Hyatt wrote: > >>On February 07, 2001 at 10:59:31, Pat King wrote: >> >>>I have seen it written here that with 64 bit Zobrist hashing, the perfect key >>>should change 32 bits. When I had what I thought to be hashing problems, I >>>captured some stats on my hash keys. I found that most of them changed 28-36 >>>bits (within 4) with a few outliers as far as 13 bits from "perfection". I also >>>checked that I was not generating duplicate keys. How good or bad is this? >>>Should I work on the average, or the outliers? Any comments appreciated :) >>> >>>Pat >> >>The main issue is hamming distance between any two positions you search. >>If each move changes 10 bits, then after 6 moves, you have potentially >>changed 60. After 12 you _could_ be back to where you started. The place >>to start working is on your random numbers. When I first did mine, I simply >>checked the hamming distance between any two of the numbers and if it was >>unacceptably low (say < 16 bits different) I culled one of them. I doubt >>you can do really bad random numbers unless you make the classic mistake of >>using two 32-bit floating point numbers and sticking them together to make >>one 64 bit random number. The problem with this is that the 'exponent' part >>of each number will be close to the same since FP random number generators >>usually produce a number N such that 0 <= N < 1.0 and that will mean your >>64 bit numbers are really maybe on 44 bits of significant bits. > >Is it also a problem if I use time as a variable seed for the random numbers? Usually not; the main issue is the generator itself, not the seed you use to initialize it. Of course you must consider at least two things: - Often random generators works better if you use specific seeds, rather than random seeds; - If you generate your random numbers at each run, it would be better to use always the same seed, in order to: 1) help debugging; and 2) allow hash codes to store information that must be kept from run to run (for example, opening books and position learning could be harder to implement if you use different hash codes at each run). 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.