Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Extension of the UCI protocol

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.