bob wrote:
This is sort of old news, actually. There are no "good" random number collections when used for hashing. But there are definitely "bad" collections. Several of us tried all sorts of approaches a few years ago. Zero improvement. You can even try some crypto-type stuff such as trying to limit the minimum hamming distance between two numbers, or minimize the sums of squares of said hamming distance, or whatever. Making sure each number has an equal number of 0's and 1's. Or trying to do the same for reasonable pairs of numbers (i.e. for knights, making sure that the from/to randoms are significantly different to affect the signature significantly. And on and on. There are lots of choices. And none of 'em helped a bit. But if you get sloppy and have numbers with too small a hamming distance, or triplets at bad locations so that a from/to number "undo" each other, we could not find any particular "advice" for producing good numbers, just so they are all reasonably random, reasonably uniform in the distribution, and none with the obvious issues of 0 or 1 bit set, etc.
I don't think you will find anything that is better than what you are using, but you certainly might find something worse.
I pretty much agree with all of the above. There are times when many pages of mathematical analysis are less revealing than a few all-night perft() runs.
What is "something worse"? I tried running
Oscar with his PRNG running with fewer than its usual eight primes. With as many as six primes, I was able to get false positives, which is
VERY SCARY for a
perft() program. (Six prime period is 30,030;
Oscar needs 105,472 bits.) Adding the seventh prime (period now 510,510) removed the false positives. But too close for comfort. So
Oscar will now use the first sixteen primes so that I may sleep better.
Symbolic uses 31 primes, which is certainly sufficient for a number of purposes including generating many billions of unique random games.