gtp March 2006

gtp@lists.lysator.liu.se

9 participants
7 discussions

Finalizing GTP version 2?
by Gunnar Farneb�ck 02 Apr '06

02 Apr '06

Recently there has been an increasing interest in adding more official commands to GTP. Considering that the current draft specification has been stable (to choose a positive word) for a very long time now I don't think it's a good idea to make those changes to GTP version 2. Some people may wonder why it's still a draft and with the risk of embarrassing myself I can reveal that mainly it has been stalled on me wanting to track down information for the Credits section but not finding enough inspiration to actually do that. To get things moving again I propose finalizing the version 2 specification by the radical approach of simply removing the empty Examples and Credits sections from the draft, then opening up development of version 3. Does anybody see a problem with this plan? Is there any fatal flaw in the specification draft that has to be fixed first? In an attempt to help development of version 3 along I've set up a Wiki at http://trac.gnugo.org/gtp. It's currently bare but you can help filling it with relevant information yourselves. /Gunnar

3 4

Re: [computer-go] More GTP questions
by Gunnar Farneb�ck 31 Mar '06

31 Mar '06

[Moved from computer-go.] Mark Boon wrote: > At the moment only category 2 is of interest now, the other two > categories I could deal with myself. I'll list them below. Most of > them are related to the state of the game. Although the GTP > definition explicitly states a certain amount of state is expected to > be kept by the engine (like the number of stones captured, history > etc.), it doesnt provide commands to query this state. Although it is > not strictly necessary to provide means to extract this information, > it can be very convenient. After all, for an engine to work > meaningfully, it needs to implement a minimal administration of the > game and knowledge about legal moves. By exposing this knowledge, a > front-end could trust the engine to provide this information > correctly, thereby reducing the complexity of the front-end. This is what I also thought once. In fact there's an entire outcommented section "Introspective Commands" in the LaTeX source for the second draft, containing the commands all_legal, is_legal, captures, color, countlib, findlib, get_handicap, get_komi, list_stones, query_boardsize. Today I'm more doubtful. The idea of a thin front-end doesn't seem all that attractive. I'd rather add board logic to a front-end than increasing the minimum requirements on the engines to interface to it. Still some commands of this kind may be worth standardizing. New people to the GTP list should be aware that the plan is to finalize GTP version 2 as is so this discussion applies to version 3. > # set_rules > arguments rules (string) > effects the engine will return moves and score according to these > rules. > output none > fails when rules are not supported by the engine > comments The engine needs to know by which rules the game is played, > it seems strange this command is missing. There are two reasons why this is missing. The first one is that it's not clear how to best design this and how to specify the different rules. The second one is that it's reasonable to assume that rules are relatively fixed, so that it's feasible to set them by other means, e.g. command line options or GUI settings, for a whole session. (This reasoning obviously didn't take the multiple rulesets of KGS into account.) Anyway, I consider this a priority item for GTP version 3 but I don't think the right approach is to enumerate a number of rulesets by name. Rather I'd like to have the rules defined by their properties, e.g. suicide allowed or disallowed, type of ko rule, territory or area scoring, points for seki or not, and so on. > # captured_by_black > arguments none > effects none > output number of stones captured by the black player (int) > fails never > > # captured_by_white > arguments none > effects none > output number of stones captured by the white player (int) > fails never GNU Go has the (private) command captures which takes a color as argument. I'm somewhat doubtful about the usefulness of this. > # is_legal > arguments vertex color > effects none > output whether a move played by color would be a legal move (boolean) > fails never This is also available in GNU Go but as has already been pointed out it takes a "move" which is "color vertex" as argument. I think this is worth standardizing. > # next_move_nr > arguments none > effects none > output number of the next move to be played (int) > fails never I think the front-end is better suited to keep track of this than the engine. Nobody has even bothered implementing a command of this kind in GNU Go, which is some kind of sign. (There are 136 commands in GNU Go, asking the engine for all sorts of things.) > # color_to_move > arguments none > effects none > output color of the next move to be played (b|w) > fails never As pointed out before the engine is not expected to have an opinion about who plays when and in any case this is mostly redundant with the following command (with the possible exception of the first move). > # last_move > arguments none > effects none > output vertex color (b|w) of the move that was last played > fails never Implemented in GNU Go (but with a "move" as output). I'm somewhat doubtful about the value of standardizing this. For GNU Go it's mostly used in conjunction with loadsgf. > # nr_passes > arguments none > effects none > output number of consecutive passes played (int) > fails never This is trivial for the controller to keep track of. > # adjust_status > arguments vertex* status (alive,seki or dead) > effects the next call to final_score will return the score with the > status adjusted at the list of points passed > output none > fails never I'm negative. If the controller wants to do fancy stuff with scoring it can count the score itself. > # thinking > arguments none > effects none > output whether the engine is currently thinking about its next move > (boolean) > fails never > comment this can be very useful to prevent undesirable re-entry of > the engine This absolutely doesn't fit with the GTP communication model. As commands must be responded to in order, this can't be answered in time to be useful. Rather if a genmove command has been issued but has not had a response the engine is thinking on a move, otherwise not. /Gunnar

2 1

Re: [computer-go] More GTP questions
by Jason House 27 Mar '06

27 Mar '06

I haven't seen a lot of response to this, so I'll post my two cents. What follows is specific reactions to the various proposed commands. If you didn't read the original post, I recommend doing that first (it's copied below my response) I find it really hard to believe that there isn't already a rules command in GTP. Is it possible that one exists but doesn't work well? If there is no such command, I'd think it really should be in there. captured_by_black and captured_by_white could in theory become a single command (accepting a color argument). is_legal seems useful for regression testing, at the very least for super ko and suicide. It might be interesting to try and consider shades of gray with this command. Filling your own eye is probably frowned upon even though it's legal... adjust_status seems interesting but may be a little too close to implementation dependent details? thinking seems interesting, but I wonder how compatible it is with the way most engines implement GTP. I'd be in favor of this command but it might not work in many cases. At the very least, this can only be done when command ids are used. I personally don't see much value in standardizing last_move, next_move_nr, and a few others. It seems like a test once, never use again type of a thing. I don't really even see it as being that useful for regression testing. Mark Boon wrote: > I'm currently looking to see what it would take to replace my GoEngine > interface by an interface that would fit GTP. Since they basically fill > the same role, except that GoEngine was only meant for Java, there must > be similarities. There are of course, but there are also some > differences. These probably fall in one of three categories: > > 1) Commands my GoEngine has but GTP doesn't and that are not strictly > necessary. > 2) Commands my GoEngine has but GTP doesn't where maybe GTP could/should > be extended. > 3) Commands GTP has but my GoEngine doesn't, which are not striclty > necessary to support. > > At the moment only category 2 is of interest now, the other two > categories I could deal with myself. I'll list them below. Most of them > are related to the state of the game. Although the GTP definition > explicitly states a certain amount of state is expected to be kept by > the engine (like the number of stones captured, history etc.), it doesnt > provide commands to query this state. Although it is not strictly > necessary to provide means to extract this information, it can be very > convenient. After all, for an engine to work meaningfully, it needs to > implement a minimal administration of the game and knowledge about legal > moves. By exposing this knowledge, a front-end could trust the engine to > provide this information correctly, thereby reducing the complexity of > the front-end. > > # set_rules > arguments rules (string) > effects the engine will return moves and score according to these > rules. > output none > fails when rules are not supported by the engine > comments The engine needs to know by which rules the game is played, > it seems strange this command is missing. > > # captured_by_black > arguments none > effects none > output number of stones captured by the black player (int) > fails never > > # captured_by_white > arguments none > effects none > output number of stones captured by the white player (int) > fails never > > # is_legal > arguments vertex color > effects none > output whether a move played by color would be a legal move (boolean) > fails never > > # next_move_nr > arguments none > effects none > output number of the next move to be played (int) > fails never > > # color_to_move > arguments none > effects none > output color of the next move to be played (b|w) > fails never > > # last_move > arguments none > effects none > output vertex color (b|w) of the move that was last played > fails never > > # last_move > arguments none > effects none > output vertex color (b|w) of the move that was last played > fails never > > # last_move > arguments none > effects none > output vertex color (b|w) of the move that was last played > fails never > > # nr_passes > arguments none > effects none > output number of consecutive passes played (int) > fails never > > # adjust_status > arguments vertex* status (alive,seki or dead) > effects the next call to final_score will return the score with the > status adjusted at the list of points passed > output none > fails never > > # thinking > arguments none > effects none > output whether the engine is currently thinking about its next > move(boolean) > fails never > comment this can be very useful to prevent undesirable re-entry of the > engine > > I would be interested to hear opinion against or in favour of these. > > Mark

1 0

Mark Boon's proposed additions to GTP
by Sanghyeon Seo 27 Mar '06

27 Mar '06

Mark Boon proposed number of additions to GTP commands. The original post can be found here: http://computer-go.org/pipermail/computer-go/2006-March/004962.html First, some of his commands have "vertex color" as arguments or output, but GTP 2 already defines syntactic entity "move" for this purpose, but in different order, "color vertex". Therefore I think new commands should use "move" instead. Specification for "last_move" command was repeated 3 times. I suspect copy and paste error. As GNU Go already implements "is_legal" and "last_move" as its private commands, it would be worthwhile to look at them. Currently: # is_legal arguments: move effects: none output: 1 if the move is legal, 0 if it is not (int) fails: invalid color or coordinate My comments: GNU Go should return boolean for this instead of int? # last_move arguments: none effects: none output: the last move (move) fails: no previous move known Compared to Mark Boon's original proposal, it prints color before vertex, consistent with other GTP commands, and specifies failure conditions. Seo Sanghyeon

2 1

GTP implementation in C++
by Paul Pogonyshev 05 Mar '06

05 Mar '06

Hi, I would like to propose my implementation of GTP in C++ for general use (under MIT/X11 license.) It is not documented, but there is a fully working example code and the code should be perfectly readable even without documentation. Maybe I'll find time for documenting it later. Major differences compared to the standard C implementation: * it implements some basic commands on its own; * it does parsing of standard commands (like `play') arguments for you; * it supports the not yet standardized extension of GTP to other games in a generic way (you can define your own games.) There are other differences as well, since it is written in a heavily OOP way with objects and exceptions and stuff. The example is Gunnar's Brown program but with GTP interface rewritten in C++. I haven't tested it thoroughly, but everything seems to work as expected. In case you wonder, I developed it as a part of Arimaa-playing engine (I'm converting it to C++.) Comments are welcome. Paul

1 1

Re: [gtp] GUI command subset
by Markus Enzenberger 03 Mar '06

03 Mar '06

On Thursday 02 March 2006 10:01, A van Kessel wrote: > As Gunnar pointed out, there are some problems when > (part of) the command fails. The natural choice would be > to require atomicity: either the command succeeds and reports 'Ok' > , or it fails *as a whole* and reports an error. I agree. > (note: undoing an undo might be difficult) I am not proposing that undo should be able to undo any command. Undo should undo exactly one move (or setup stone), undo_multiple <n> should undo exactly n moves (or setup stones). As for the setup command: the main reason that I really need it are the silly SGF trees, that our Go engines create internally, if I transmit setup stones as play commands. It is intended to be an optional command, so if a Go engine cannot handle it, it simply shouldn't support it. Then the GUI can still fall back to sending setup stones as moves (with the mentioned problems), or simply refuse to attach a Go engine to a position that contains setup stones. SGF is still the de-facto standard. This is not going to change any time soon. Even your GUI Quarry allows to add setup or remove stones at any position in the game tree. Why would you not allow to attach a Go engine to such a position? I can understand that a normal user mainly wants to play games with a Go engine. But a Go programmer needs to load SGF documents, attach his Go engine to it, and run different commands on the position. - Markus

2 2

GUI command subset
by Markus Enzenberger 02 Mar '06

02 Mar '06

Hi, I would like to propose a new optional command subset for graphical user interfaces. The main problem it tries to access is the excessive number of play and undo commands when navigating in games, which slow down GUIs and are not very human-readable. Here are the proposed new commands: play_sequence <color> <move> [<color> <move> [...]] Example: play_sequence b c3 w g7 b g3 Like the play command, but can take a sequence of moves. The development version of GoGui already uses this command, if supported by the engine. This command requires that the engine has no limit on the command length, because the argument length can become large. undo_multiple <int> Example: undo_multiple 3 Like the undo command, but with an argument that tells the number of moves to undo. GoGui presently uses the GNU Go gg-undo extension command, if supported by the engine. The command should have a different name from the simple undo command to avoid problems with engines that support only simple undo and don't check if the command has an argument. setup <color>|empty <point> [<point> [...]] Example: setup b c3 g7 Setup stones. GoGui presently sends setup stones as play commands. This has two big disadvantages. First, a play command will kill blocks with no liberties, a setup stone does not. Second, the engine does not know, that the setup stones are not regular moves. For example, if the engine has a command to save SGF traces of a search (like GNU Go and Explorer have), and the search is done in a setup position, then the setup stones show up as moves in the SGF trace and it is difficult to find the actual start position. Color empty means removing a stone. If the engine supports the setup command, then undo should undo the last play or setup command. - Markus

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp March 2006