Author: Chuck
Date: 15:38:07 07/02/01
Go up one level in this thread
On July 02, 2001 at 15:01:48, Dann Corbit wrote: >The opening book is certainly one of the most important parts of a chess >program. > >Thus far, I have seen no example which contains all of the information I would >want. Therefore, I think there is no agreeable standard. > >There was some discussion on this idea in a German newsgroup a while back. > >Here is a bare minimum of the sort of data I think should be present: > >1. What is the total count of persons making this move by ELO bins? >1a. (related) What is the average ELO of a person choosing this move? >2. What is the win/loss/draw count for each choice [by ELO if possible]? >3. What is the computer evaluation for this move? >3a. (related) What is the depth in plies of the computer evaluation? >3b. (related) What program was used to perform the evaluation? >3c. (related) How many nodes were examined? (useless without 3b.) >3d. (related) What is the extrapolated mini-maxed score for this choice? >3e. (related) What are the statistics for the mini-maxed score? (multiple >components) >4. What is the MCO evaluation for this move? >5. What is the alternative human evaluation for this move? [E.g. Najdorf >opinions from Nunn's book, etc.] >6. What are the statistics for when *my* program uses this move? (It may be a >great move, but if the computer does not understand it, it isn't a good move for >that program). >7. What is the average time control for the human games at this choice? >8. What is the average time control for the computer games at this choice? >9. What is the average time control for the computer-human games at this >choice? > >I'm sure that there are lots more things that I can't think of right now. > >The information should be stored in a "real database" -- not some binary file. I think you have covered just about everything that could be wanted, Dann. However, I would like to add two more fields - one to store a program generated "selection frequency" value and one for a user-entered "selection frequency" value. This way the program may default to using it's own selection rules under some conditions, e.g., computer matches, or take the user's advice under others. Also, I think that some of the columns mentioned, like the ones which fall under #3 above, are nice from a database perspective, but from the perspective of a playing engine, they are not very useful, would take up space and slow down database retrievals. One reason I pick out number 3 is because 2 years after you completely analyzed your database with Crafty 17.x and Crafty 19.x is out, this data may be essentially useless. So perhaps some items should be considered optional to track, i.e., say the user builds an opening database from a large pgn file, they would be given an option for some items whether they would be tracked in the database. Then the programmers could specify the optional items as useful to their engine or not, and users could build a database appropriately. With this issue we have to keep in mind that the database may be very large, with millions of records, and each field added to the record has the potential to impact performance. Lastly, a standard database driver would be nice, but we would need one for Windows and one for Linux at a minimum. It would be nice as well if they performed at nearly the same level and scaled database sizes equally well. Of course, writing database drivers is not nearly as fun as chess engines, huh? All in all, I think this would be a very good idea, and I would like to see some others contribute their thoughts. Chuck
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.