Author: Vincent Diepeveen
Date: 06:08:49 04/18/04
Go up one level in this thread
On April 17, 2004 at 05:35:31, Vasik Rajlich wrote: >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 That's where i disagree with Stefan fundamentally. The engine should do it's own book + learning and handle pondering for itself. > >> >>>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.