Author: Vasik Rajlich
Date: 02:35:31 04/17/04
Go up one level in this thread
On April 16, 2004 at 14:17:04, Vincent Diepeveen wrote: >On April 16, 2004 at 13:33:49, Russell Reagan wrote: > >>On April 15, 2004 at 15:31:22, Stefan Meyer-Kahlen wrote: >> >>>* ucinewgame >> >>Hello Stefan, >> >>Why did you guys choose a 'new game' command as opposed to a command like >>'result 1-0'? I think a 'result' command would fit better into your stateless >>approach, and allow for book learning better than a 'new game' command. > >>Here are some examples where I think a 'result' command would be more clean and >>stateless than a 'new game' command. >> >>Let's say my engine just won a game. Does it get the ucinewgame command >>immediately after the game, or does it only get the ucinewgame command > >don't count at it when running under fritz9. > >they'll find a way to nullify your learning. Under UCI, the engine shouldn't be doing its own learning anyway. That's a job for the GUI. Vas > >>immediately before the next search? What if the game ends, then the user closes >>the GUI? Will my engine ever receive a ucinewgame command? If it doesn't, I >>can't do any book learning. >> >>When my engine receives a ucinewgame command, it seems like my engine has to >>keep track of what is going on in the game internally (not stateless) so that it >>can go back and decide how to change the book moves. I think a 'result' command >>that worked like something like this would be better for your stateless >>approach: >> >>result 1-0 moves <insert game moves here> >> >>Then the engine doesn't have to keep track of anything internally. It gets told >>what to search, when to search, etc., and when it wins, it gets told that it >>won, and gets the complete game history. To me that is more stateless than the >>engine trying to keep track of what is going on in the game. >> >>Now, if my engine checkmates the opponent, and then I get a ucinewgame command, >>then I can clearly determine that I have won that game (since the final position >>is checkmate). What happens in the sitation where my engine cannot tell what the >>result is? In that case, the ucinewgame command doesn't seem to help. What if >>the opponent resigns, or one of us loses on time? Will my engine have any way of >>knowing what the result of that game was (other than guessing)? A similar >>situation arises when my engine would process a test suite. After each position, >>it gets a ucinewgame command, but to my stateless engine, it would not know >>whether this was the start of a game or just a test position. In other words, I >>have no way of knowing whether to do any kind of learning or not. >> >>I think that since there are some useful things to both a 'new game' command and >>a 'result' command, that it would be nice to have both. Maybe there could be two >>'position' commands. >> >>position [fen <fenstring> | startpos ] moves <move1> .... <movei> >>newposition [fen <fenstring> | startpos ] moves <move1> .... <movei> >> >>And a result command: >> >>result <result> [white <name>] [black <name>] moves <move1> .... <movei> >> >>Example: >> >>result 1-0 white Shredder black Russell moves 1. e4 e5 2. Qh5 a6 3. Bc4 Nc6 4. >>Qxf7# >> >>The 'newposition' command would be useful for running test suites, or starting a >>new game. The 'result' command could add in enough information for the engine to >>save its own PGN file, or at the very least have enough information to do book >>learning. >> >>In any case, I'm glad to see that you are all still working to improve the >>protocol. It is really nice to work with UCI engines as a user.
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.