RKISS

[rbarreira]

random.org has all the random Zobrist numbers you could possibly want. I don't see much reason to fiddle around with PRNGs when that is available.

[bob]

random.org has all the random Zobrist numbers you could possibly want. I don't see much reason to fiddle around with PRNGs when that is available.

We need 'em for other things... Such as helping with random book move selection. And perhaps a random factor added into the eval when trying to lower the programs skill level...

[Kirill Kryukov]

The problem would be that each "initial state" would have to be thoroughly tested for randomness. Which is a big effort. A good PRNG has a huge period. Sucking away the first 1000 values for the Zobrist keys (I have mine statically defined so that I can change the PRNG if I want) and then sucking away N where N is a random number from either /dev/random, the low N bits of the wall clock time or whatever, seems quite reasonable, as opposed to taking the chance of choosing a poor initial starting state that has lousy properties...

Sorry for jumping in. A few comments.

Regarding initialization, I too think that skipping N first values is a horrible way of initializing a PRNG in general, although it may be OK for some uses (where you don't care about repeating the same sequence in different runs).

I remember a while ago Bob posted strange results from some crafty test runs on a cluster, where observed correlation between games was much more than expected. I wonder if this simplistic initialization could result in such artefacts.

When I initialize a PRNG, I generally do this: I collect entropy from various available sources (time(), hi-res timer, input properties, client properties in a web server scenario, etc), pack it all into a string, then compute a hash of that string (e.g. MD5), then use that hash as a seed.

Regarding the PRNG choice, has anyone tried WELL? In theory it provides quick recovery from bad initialization, and good chaotic state behavior.

Someone mentioned that PRNG in a chess engine is mainly used for 1. book moves 2. simulating an artificially weakened player. Both tasks don't seem like requiring the top performance PRNG, so there is no excuse for not using a proper PRNG.

Best,
Kirill

[bob]

The problem would be that each "initial state" would have to be thoroughly tested for randomness. Which is a big effort. A good PRNG has a huge period. Sucking away the first 1000 values for the Zobrist keys (I have mine statically defined so that I can change the PRNG if I want) and then sucking away N where N is a random number from either /dev/random, the low N bits of the wall clock time or whatever, seems quite reasonable, as opposed to taking the chance of choosing a poor initial starting state that has lousy properties...

Sorry for jumping in. A few comments.

Regarding initialization, I too think that skipping N first values is a horrible way of initializing a PRNG in general, although it may be OK for some uses (where you don't care about repeating the same sequence in different runs).

I remember a while ago Bob posted strange results from some crafty test runs on a cluster, where observed correlation between games was much more than expected. I wonder if this simplistic initialization could result in such artefacts.

In my cluster testing, there is no PRNG use of any kind. I have initialized the Zobrist numbers statically for several years. And I don't use any book or anything else in cluster testing, so no random numbers are used/needed.

When I initialize a PRNG, I generally do this: I collect entropy from various available sources (time(), hi-res timer, input properties, client properties in a web server scenario, etc), pack it all into a string, then compute a hash of that string (e.g. MD5), then use that hash as a seed.

Regarding the PRNG choice, has anyone tried WELL? In theory it provides quick recovery from bad initialization, and good chaotic state behavior.

Someone mentioned that PRNG in a chess engine is mainly used for 1. book moves 2. simulating an artificially weakened player. Both tasks don't seem like requiring the top performance PRNG, so there is no excuse for not using a proper PRNG.

You need to call this thing once for every node evaluated. That is a huge number of calls and performance is critical...

Best,
Kirill