World Championship Winning Computer Chess Software Program & Downloads for Chess Databases, Analysis and Play on PC, Mac, iPad and iPhone — Visit: Hiarcs.com
This is very interesting. I'm assuming all moves were programmed to be legal chess moves. Slightly similar to the novice game "No Stress Chess" where the piece to move is dictated by a random card draw - but in this case on steroids...
How were pawn promotions handled - did it default to a Queen? Or, was it programmed to under-promote to avoid stalemate situations?
Was there any significant statistical difference on the white versus black checkmate? Curious to know if white had a slight advantage with the first move.
It would be interesting to see how a couple of checkmates occurred (out of the 153 million) . I wonder what percentage were just brute force traps by major pieces versus a lucky random move of a minor piece or pawn. Did you have a chance to view the details of any of the games?
fourthirty wrote: I'm assuming all moves were programmed to be legal chess moves.
To clarify - I'm trying to understand if the random generator FIRST randomly picked the piece to move, and THEN picked one of the legal moves (if available).
Or, did the random generator look at ALL the possible legal moves from ALL the pieces on the board and choose from that population?
Thanks for sharing parts of your code! I do not speak C++ very well (FORTRAN 77 was my last programming class). However, one of my fellow engineers is somewhat fluent, and we reviewed the code yesterday.
We assumed that gmvec function is the set of ALL the legal moves computed from your chess engine. Then, instead of your engine calculating the relative strength of the legal moves, the RandomPick function selects one move from the set & assigns the vector to the variable "move".
fourthirty wrote:We assumed that gmvec function is the set of ALL the legal moves computed from your chess engine. Then, instead of your engine calculating the relative strength of the legal moves, the RandomPick function selects one move from the set & assigns the vector to the variable "move".
The program is now working on a ten billion game run which should take a total of about 23 days of single core CPU time.
However, that may be too long of a run since the random number generator in use has a period of about 2^34 (ca. 34 billion). Each random game requires on average about 334 random numbers.
The arc4random() routine is better than the earlier random() routine, but is not part of the built-in library on Linux or on older versions of OpenBSD. So I don't use it as my code must remain as portable as possible.
The arc4routine() is somewhat tainted, however. Designed by RSA back in the 1990s, it has become suspect due to very recent revelations by Edward Snowden that the NSA paid RSA to deliberately compromise some of their products to make government intercepts easier.
On nearly all Unix systems, the pseudo device /dev/urandom produces good quality random bytes quickly. But its stream is different each time it's accessed, so hash codes built from it will also be different each time they are constructed.
I have my own C++ random bit stream generator, a high quality source which is used to make hash codes which are independent of the host platform. But it runs much, much slower than random() and so is a poor choice for billion game runs.
sje wrote:The program is now working on a ten billion game run which should take a total of about 23 days of single core CPU time.
It will be interesting to see how the outcome statistics change (I wouldn't expect much). However, if you are a believer in the Shannon Number, 10 billion is a small statistical sample of the number of possible games.