Author: Vincent Diepeveen
Date: 06:10:41 04/18/04
Go up one level in this thread
On April 18, 2004 at 09:08:49, Vincent Diepeveen wrote: The example i can give why it is useful is that diep also works under *nix systems like linux, irix etc. No GUI's there. >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.