Comments?
Yes, I think we are getting somewhere now. The programs do need a way to understand what the level is, even if they don't really use that information, we can't assume this. I'm not familiar with tournament practice and so will need a little help.
What time control conditions are in widespread use? Is it similar to tourament chess? ie:
. Game in x minutes. . n moves in x minutes
and in programs we might see levels like:
. Average n seconds per move.
Some older programs have something as simple as level 1, 2, 3 etc without this being really defined in terms of playing time, perhaps like gnugo's levels of 1-10.
One thing about gtp as I understand it, it seems to be command driven, an interface gives commands and gets back a response. There is no provision for the engine to initiate communication beyond this, unless we do it on another channel. I'm not sure we really need this, but it might be useful (while more complex.)
One thing I would like to do, is to command the engine to stop searching and play immediately. This is useful for long thinks, if your engine is capable of thinking for long periods of time. But if the interface is waiting for a move to come back, is it forbidden to send a 'move_now' (or even 'quit') command? Things get out of sync, especially if you do not use the id feature of GTP.
Don
From: "Anders Kierulf" anders@smartgo.com
Although this appealed to me at first, I have this feeling that whatever we do on the first pass, will end up being the defacto standard and nothing beyond this will likely get implemented. We will live with it for years! Maybe we should make some effort to make it complete enough to serve us well?
I agree. This is the time to get it right. The command set needs to be sufficiently complete to allow sophisticated arbiter programs. If the command set is too minimal and e.g. requires manual setup of the programs between games, we've lost a lot of the advantages the GTP could offer over GMP.
So what if we add something like this? (I need feedback here)
ko setup ruleset set_level version
[...]
Don
This is a good start. A comment to set_level: SmartGo doesn't use levels, it uses the time available to determine how much time to spend on a move. So for generating a move, SmartGo needs to know whether this is part of a game being played (and how much time is left in the game), or whether it's just an individual move to generate within a given amount of time, such as 20 seconds.
One thing that has not been discussed much so far is the state we expect each program to maintain. Once we define the minimal state a Go program has to maintain, it may be easier to identify the appropriate commands, and it may also help define each command more precisely in terms of how it affects that state.
At a minimum, I'd expect each Go program talking GTP to know the following: (A) Board size. (B) Komi. (C) Handicap (fixed handicap, or remaining moves to play using arbitrary placement of handicap stones). (D) The ko and scoring rules in effect. (E) Board position. (F) Whose turn it is to play. (G) Enough knowledge of the history of the game to identify ko and repeated positions.
(A)-(D) get set up at the beginning of the game, while (E)-(G) change with each move played.
For each move to be played, the program needs to be told: (H) Time left (if this is a game rather than a problem position), or time to use for generating this move.
In addition, the program must be told (or have a way to request) the following information: (I) The time and overtime rules in effect (e.g. need to complete the first 250 moves within one hour). (J) If playing a game, the name of the opponent program. Many programs may ignore this information and will just play as fast as possible and not make any distinction between opponents, but if GTP is used to fully automate computer Go tournaments, I think this is needed.
Comments?
Anders Kierulf www.smartgo.com
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp