Author: Vincent Diepeveen
Date: 11:17:04 04/16/04
Go up one level in this thread
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. >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.