Author: Dann Corbit
Date: 15:52:32 07/02/01
Go up one level in this thread
On July 02, 2001 at 18:38:07, Chuck wrote: >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. I plan to populate this field with CAP data. I have 20 million positions at 12 minutes or better of CPU time. Even ten years from now, it would be useful for blitz. To extract a single forward ply with a hashed index would be a few milliseconds. I also have 200 million positions analyzed at a few seconds each. While I don't think you should use those raw data points to make any chess decisions, they can be minimaxed, and possibly produce useful results. Besides which, the data gets updated as time goes along anyway. And as my chess engine plays, it will update the statistics during play. I have another plan to create a "chirping crafty" which will essentially send a 'ping' to a server every time a move is made. This data will be compared to the database answer. If the data is superior (meaning deeper, or the same depth with a newer version, or did not exist at all, etc.) it will be replaced in the database with the better data. >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. There is an ODBC driver for Linux available in many places, and so the source code base could be identical. >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? Hard to say. I do both. Both have rewards (and punishments) ;-) >All in all, I think this would be a very good idea, and I would like to see some >others contribute their thoughts. Me too.
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.