Author: Danniel Corbit
Date: 14:29:09 09/25/98
Go up one level in this thread
The biggest problem with opening books is that they are a horrible design from start to end. It makes me whinge in pain when I think about how they are designed. 1. If an opening has been played several times by good players, it may be used, even though it contains a tactical hole. 2. The depth in plies of opening books is very non-standard. How far out should we trust them? 3. If we want to store millions of moves, getting at the data and updating the book will become problematic. The answer is a database. Then, standard access could be had via ODBC, SQLMOD, embedded SQL or whatever. In this way, very rapid access to billions of records can be performed with incredible ease. Updates, inserts and deletes are handled with ease. The database can increase in knowlege over time. We don't have to make black and white decisions like "NEVER PLAY THIS MOVE" or "ALWAYS PLAY THIS MOVE" unless we find a compelling reason to do so. The detail level record should be a compressed version of epd, with some other information from EPD analyis. For instance, here is an EPD analysis from Crafty: 1b1r4/p4p1k/1p3n1p/1Pp4b/P1Q1pq2/3P1P1P/1BRR4/5B1K b - - acd 4; acn 8333; acs 1; ce 32752; pv Bxf3+ Kg1 Qe3+ Rf2 Rg8+ Bg2 Rxg2+ Kf1 Rg1+ Kxg1 Qe1+ Rf1 Qg3+ Rg2 Qxg2#; I would throw out the acs, because I could care less how long the problem was worked on. Faster or slower machines might be employed, but if they worked longer or had more horsepower they could come to a better conclusion. In this particular case, a solution is discovered, so I should like to post process the record and add 'bm Bxf3+;' I would store the node count, and plies, as these are useful to know if I should reprocess at a certain time control [if I know how fast my machine is and how much time I have left...]. If a great number of nodes were processed, I should also like to store the pv. In this case, it hardly seems necessary, as a solution is discovered instantly. [On the other hand, since it leads to mate, a future algorithm might miss it so I would probably store it anyway]. We can create a unique clustered index on the EPD position. We might store an alternate key (non-unique) of the zobrist hash of the position, to allow computers to do lookups either way. We should also store the number of wins, losses and draws from this position [possibly also the number of incomplete games]
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.