gtp

gtp@lists.lysator.liu.se

164 discussions

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

[Fwd: Re: [gtp] boardsize and clear_board]
by Joan Pons Semelis 20 Jul '05

20 Jul '05

Oops! I did not reply to the list before .... -------- Original Message -------- Subject: Re: [gtp] boardsize and clear_board Date: Mon, 18 Jul 2005 13:43:12 +0200 From: Joan Pons Semelis <SEMELIS(a)terra.es> To: Chris Spencer <ckspencer(a)verizon.net> References: <200507171946.j6HJkVKC003953(a)koeberg.lysator.liu.se> <42DABE96.4050507(a)verizon.net> Chris Spencer wrote: > Gunnar Farnebäck wrote: > >> The reason to introduce clear_board was that it seemed silly to be >> clearing the board as a side effect of setting the boardsize. It would >> have been an option to still require boardsize to also clear the board >> but I thought it made more sense to have those commands orthogonal. In >> part this is also a symmetry with not requiring the board to be empty >> at startup, which is useful when you can specify an initial position >> externally (in the case of GNU Go as a command line option). >> >> > Only the only problem I see with this rationale is that I can't think > of a situation where I would resize the board without clearing it. > Resizing the board without clearing results in a board with an > essentially meaningless piece arraignment. Is there really a useful > case where you would resize the board but wish to save the positions > that weren't truncated as a result of the resizing? > Yes: setting up a joseki of the type territory versus influence and cheking again different sizes and rest of the board positions to see how the influence side of the joseki works. You can do this to a limited extend even in sgf format, and I use this feature from time to time. > I agree that it's intuitive to have a clear_board command. However, > not clearing the board after a resize seems unintuitive to me. > > Sincerely, > Chris Spencer > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp > > -- Joan Pons Semelis http://www.terra.es/personal8/semelis/go -- Joan Pons Semelis http://www.terra.es/personal8/semelis/go

2 2

boardsize and clear_board
by Markus Enzenberger 20 Jul '05

20 Jul '05

GTP version 2 has been a draft for nearly 3 years now, but it is becoming the de-facto standard for many programs. Still, maybe it is not too late to discuss some basic commands. I never understood why version 2 introduced the clear_board command. What is the point of a separate boardsize command, if the engine's state is undefined after the command and you still have to send a clear_board? If the idea was to avoid a complete initialization of the Go engine, that is something the engine could easily do internally. - Markus

5 10

Question on GTP Echo Request-Response Sequence
by Preeti Sharma (presharm) 09 Jun '05

09 Jun '05

Hello List, Can anyone please tell me what the intended behavior of a GTP node (GGSN /SGSN) should be in case it receives a echo Response without a corresponding echo request, is there a error code for this that I cannot find. Thanks. Preeti.

2 1

gnugoclient-3.0
by Gunnar Farneb�ck 14 Sep '04

14 Sep '04

I have released gnugoclient version 3.0. Gnugoclient is a program which can be used to connect GNU Go and other go programs to NNGS and compatible servers and have it play games without supervision. The requirement on the go program is that it supports the Go Text Protocol (GTP) and can communicate either over TCP/IP or via pipes. Gnugoclient is written in Pike and should work on any platform where Pike is available, which means almost any brand of Unix plus Windows. It has been developed on Debian GNU/Linux and tested on Solaris 9. It has also been briefly tested on Windows XP and at least the basic functionality seems to work. New features compared to version 2.0: * GTP version 2 compliant. GTP version 1 support remains but is deprecated and untested. * Simplified configuration. * Support for connecting to GTP engines both over pipes and TCP/IP. * Automatic level adjustment removed. Time information is now sent with GTP commands, leaving level adjustment to the engines. * Works with GNU Go 2.7.245 and later and other GTP compliant go engines. * Specific support for the Gifu 2004 tournament. Further information and a download link are available at http://www.lysator.liu.se/~gunnar/gnugo/gnugoclient /Gunnar

1 0

No I?
by Chris Spencer 11 Sep '04

11 Sep '04

I suppose this may be explained somewhere, but I've been at a lose to discover it. Why do GTP coordinates not use the letter I? SGF uses I, or at least doesn't mention it explicitly (http://www.red-bean.com/sgf/go.html). Most non-GTP go board markups I've seen use I. Sensei's Library lists some answers to this question, but they seem fairly vague and inconclusive. Is there a real reason or is it just convention? Chris

3 2

Jump to page:

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