Author: Dann Corbit
Date: 23:27:12 01/31/99
Go up one level in this thread
On January 31, 1999 at 12:40:30, James Long wrote: >On January 31, 1999 at 00:42:27, Dann Corbit wrote: > >I think this is a great idea, and I'm definitely interested, >but there is one issue: > >While this book could be the best researched book on the >planet, what good is it if every other competing program >uses it? That nullifies any advantage one program had over >the other in the opening, especially if one move is identified >as the "best move" from a given position. We could ask the same question of Eugene Nalimov's tablebase files. You don't have to use them, but if you don't you are simply going to get creamed in the end game. I have a huge number of goals for the project. One of the goals is for computers to play better chess. This is one way that will be possible. Obviously, I could have tried to keep things a secret or make each programmer write their own API. I don't think that would have been better. I really hope that coupling the creativity of the human mind and researching the data we may get better understanding of the openings, middle, and end of the game. Incidentally, the most frequently appearing positions in chess games are not just in the openings. So sometimes the book will have engame information, but before you get to the tablebase files. I plan to share anything I learn and to make all the data publicly available. What is more, it will be free to use the code and data I produce with no fees or royalties of any kind, both in free programs and commercial ones. Public domain. It may still be possible to give your program an edge by the way in which you use the data. You can refine and recombine the data in any way you choose. You can put energy into solving particular lines, whereas right now, I am doing a very broad survey. >Will gambits be allowed in the book? If so, what about >some sort of flag to identify the move as a gambit, so that >programmers who want to avoid them can do so. Everything is allowed in the book from an opponent checkmate to a checkmate for the current player. I have no plans to try to recognize gambits. I think it would take some kind of AI to differentiate a gambit from an idiotic blunder of a pawn. I often can't tell which is which myself. It will just be a fast lookup of data. I want to provide a format most easily recognized by many programs, or at least documented so that anyone can understand it. >That aside, my vote would be for a C implementation. Those >using C++ can create their own classes for encapsulation. > >Every position should allow for multiple moves. We don't >want a program that plays the same openings over and over. >It would be nice if there were "open fields" to allow the calling >programs to store their own data (like win/loss counts or >learned values). I plan to make a two way API. You can read from the book, you can write to the book. >As far as the pv goes, I could care less either way. While >that data is certainly nice to have, it may just take up >more room than it's worth. Perhaps that is one field that should be optional. >I've yet to decide on any kind of format. >I'll think about it for a while and write more... :-) I appreciate any feedback that you can give. >--- >James > > > >>I am going to create a special opening book that uses the C.A.P. data. It will >>also contain some middlegame and endgame stuff in it, but most programs will >>have little interest in that. What I would like to know is what API would you >>like to use? I can make it a C API or C++ objects. I also would like to get >>your thoughts on what the volume of information you would like back is. I will >>have a suggested move for all positions, a best move for some positions, and an >>avoid move for a few positions. I will have a pv -- how much of that would you >>like and in what format? I will have a ce. Would you like second guesses also >>(I have tables with the same information but did not get run as long and >>occasionally the answers are different) or best answer only? What should the >>format for the positions be? If binary rather than character string, what >>format will convey the all the information that everyone needs? I can possibly >>start up the inquiry data structure with various attributes depending upon the >>way it is constructed. I will also have an interface to update the database. >>That way, it can grow in information over time. >> >>What I would like is a clear specification that would benefit the broadest >>possible range of programmers with the greatest possible utility.
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.