mvk wrote:Some random points:
- The hash collision rate seems wrong, or your hashing method is too weak.
Multiple persons said this so it must be true
I store all data in a mysql database. Very convenient.
Now 369494 hashes out of 3290575 unique (fen-)entries have 2 or 3 collisions.
I looked at one and it looks like this:
Code: Select all
mysql> select * from entries where hash=-9221985131600632708;
+----------------------------------------------------------------+----------------------+-------+------+
| fen | hash | plies | eval |
+----------------------------------------------------------------+----------------------+-------+------+
| rnbqkbnr/1ppppp1p/8/p5p1/1P1P4/6P1/P1P1PP1P/RNBQKBNR b KQkq - | -9221985131600632708 | 15 | 23 |
| rnbqkbnr/1ppppp1p/8/p5p1/1P1P4/6P1/P1P1PP1P/RNBQKBNR b KQkq b3 | -9221985131600632708 | 16 | 29 |
| rnbqkbnr/1ppppp1p/8/p5p1/1P1P4/6P1/P1P1PP1P/RNBQKBNR b KQkq d3 | -9221985131600632708 | 16 | 23 |
+----------------------------------------------------------------+----------------------+-------+------+
3 rows in set (2.23 sec)
I checked this for 5 more and it is always one without pawn move and then the other 2 colliding entries are a pawn move.
A bit puzzling. Thinking out aloud: so what I think happened is that the b3 one did earlier d3 and vice versa. Then you would indeed end up with the same fen-string (apart from the en-passant field) and also the same hash-code. If that is indeed what is happening, then I would expect to have maybe even 8 collisions.
- Storing plain FENs is perfectly ok for books and simplifies code. I use one line per move, repeating the FEN on each line. No sweat. This way I can just use the Unix 'look' command with popen() for a binary search on the file. No need to cram bits these days.
Yeah totally agree. I take it a step further by storing the data into mysql. For 3.2 million records the search-time is less than 0.00 seconds.
- I would advice to do exclusion searches. This way you can chain the book positions into a big tree, minimax it, and get higher quality moves near the root.
What is an exclusion search? I googled it but got no relevant hits.
- Are you proposing a 7-ply full width book? At least you can apply the alpha-beta logic and skip most positions. Maybe I misunderstand. perft 7 is much larger than 2.5M, and sqrt(perft 7) is about 60k.
Yes. The values given was not the final 7-ply result but somewhere between 6 and 7. Also it will become slightly more than 7-ply nodes because I do quiesce search as well.
So I calculate the evaluation of all moves in the first 7 plies (+quiescence) and for each of these 3.195.901.860 moves I do a 15-ply search. Hmmm maybe I'll cut that back a bit; that would take 100 years with 1 second per move
- Don't do fixed-depth searches. Strength correlates with nodes searched more than with depth reached (given the same program). There is a lot of variability among same-depth positions. I switched to using a node-count based search for my book when it became larger.
Yes I was planning to let my script update things after an initial fill. I want to have some initial data so that I can experiment with it. The script that retrieves the fen-strings from the database and then sets the score (+depth) is implemented so that it can do a fixed-depth search OR a fixed-time search. In fixed-time it can check if it reached a greater depth and then update he record with the newly found score.
- 1 second is too low if you want to use the move at time levels that are slower. First order, the time advantage for playing a book move at once doesn't compensate the quality problem of playing a shallow move.
Yes the 1-second was the result of the selected ply-depth.