Author: Dan Newman
Date: 17:22:18 02/08/01
Go up one level in this thread
On February 08, 2001 at 10:45:40, Carmelo Calzerano wrote: >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 One thing you probably should do is use your own random number generator instead of the one that comes with your compiler. There are two reasons for this: 1) The one that comes with the compiler is often severely limited. The one that came with MS C a few years back was a 16-bit RN generator, for instance. Yuck, I just looked and it's still that way... I suppose it might be the ANSI standard... 2) If you re-compile with other compilers, you'll get different results with the built-in RN generator. This will, of course, make comparisons rather difficult and will require re-building books and so forth. What I did was generate a file of random numbers that my program reads in on startup. That allowed me to burn a lot of CPU cycles to get a fair set of random numbers and guarantees that I always use the same set. -Dan.
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.