Yes, its been discussed here more than once. Maximum hamming distance between pairs of your 769 keys doesn't mean squat, because real board positions will have lots of those keys XORed together -- usually a dozen or more of them.bob wrote:A couple of years ago we had a PRNG debate here. I tried several and found _zero_ differences with respect to Elo. You will find one set of random numbers that works better on a given set of positions, another set of random numbers that works best on a different set of positions. There is hardly any PRNG around that can't spit out 1,000 decent random numbers. The issues come way later when you get into cycles. I've never seen one that would think about cycling after just 1,000.Milos wrote:PRNG tests are pretty standard. But does it necessarily mean that something that is better in PRNG tests is better strength wise?bob wrote:Worse in what way? There are a series of tests, poker test, runs test, uniformity test, etc, that should _all_ be used to screen PRNGs. The MT algorithm has been pretty thoroughly tested. Particularly since we only need a few numbers and not millions.
Not necessarily, at least according to what I've tested.
I've tested with 3 different hash sizes (8MB, 32MB, 128MB) and 3 different TCs (1'+1'', 40/4', 40/20') and never got a version with MT (I used the default seed) outperforming the original version (within error margins - it was 2k games self-test). As a matter of fact, the original version was almost always better (on one occasions even with LOS over 95%).
I think trying to measure effectiveness is hopeless for such tiny potential changes... 2K games is nowhere near enough as the potential gain is in the +/- 1 Elo or less, unless you have some horrible PRNG. The twister is hardly horrible. I use the PRNG from Knuth's book since the source (in C) was publicly available.
Choosing decent 64-bit pseudo-random numbers is all you need to do to get a very low collision rate. (I don't think anyone has demonstrated an alternate technique for choosing keys that gives significantly better collision rates than just using pseudo-random values).
If you have BAD psuedo-random numbers, you might get more collisions than you should (e.g. if you just used rand() and didn't notice that it only gives you a 15-bit number!). If you use a PRNG like the Mersenne Twister, and make sure you're actually putting 64 bits of output into your 64-bit keys, then everything will be fine.