Author: Russell Reagan
Date: 10:33:49 04/16/04
Go up one level in this thread
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 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.