gtp July 2002

gtp@lists.lysator.liu.se

6 participants
9 discussions

Re: [gtp] draft_v2
by William M. Shubert 01 Aug '02

01 Aug '02

On Thu, 2002-07-18 at 03:00, A van Kessel wrote: People actually play 8x8 ? I'll give NNGS a peek. Run on the KGS server's SQL game database: mysql> select from_unixtime(date_stamp/1000),black,white from games where board_size = 8 and owner is null; +--------------------------------+------------+-----------+ | from_unixtime(date_stamp/1000) | black | white | +--------------------------------+------------+-----------+ | 2001-02-01 05:43:23 | faz | Sean2win | | 2001-02-07 13:45:41 | Lantu | sencha | | 2001-04-25 12:38:04 | jefounet | atadano | | 2001-05-30 05:23:07 | JJ | kaz | | 2001-06-21 15:37:25 | nickwild | dezomb | ... | 2002-07-10 13:05:28 | bgoodwin | pinhead | | 2002-07-10 13:23:49 | bgoodwin | touyo | +--------------------------------+------------+-----------+ 117 rows in set (3.35 sec) So people do play 8x8, just not very much (117 games out of about 400,000 in the 2+1/2 years that KGS has been around). I think, communicating a vertex in %c%u format is pretty standard. Just stay with the hurd... paperware,IGS,NNGS: %c%u GMP: %u SGF: %c%c Kiseido: Propriety ? KGS sends all coordinates as two bytes, "\0\0" beang the lower left, "\22\22" (two 18's) being the upper right and "\377\377" being a pass. But overall, I think this is all pretty unimportant - GTP should be implemented in whatever way makes sense for GTP, not in whatever way matches some server protocol. After all, if you are connecting GTP to a server, converting the vertex format will not be any difficulty. I am not aware of any free-handicap implementation. Just passing will do for most cases. But, the real reason for wanting it in the protocol, is cause of the HA[] in the game record, I guess. For the rest, the position can just be set up (by AB[],AW[], play) , and komi set seperately. KGS does indeed implement free handicaps for Chinese and New Zealand rule sets and players are using it. It seems to me that the GTP handicap system is both complex and restrictive. Why not just have a "handicap <n>" command, which specifies the handicap; then for fixed handicap, follow that with a series of "play b <location>" commands; for free handicap, follow the "handicap" command with a series of "genmove b" commands? That seems simpler to implement and more flexible, because now the arbiter in a game can do the handicap any way it seems right, the protocol no longer forces a particular handicap placement system. The only real need of the "handicap <n>" command at all is so that programs can (if they choose) move differently for the 1st handicap stone of 5 vs. the 1st move of a non-handicap game. Another thing that really stood out to me as troublesome (other than the protocol telling you where your handicap stones have to be) is the "time_settings" command. It only supports canadian time and it is not very extensible. Canadian is AFAIK only common on the IGS/NNGS/etc. go servers, nowhere else in the world is it the dominant go clock system, so making it the only time system for GTP seems bizarre. At the very least shouldn't there be an argument specifying the time system? For example "time_settings canadian 30 10 25". Then in later versions of the GTP spec if necessary we can add "time_settings japanese" or "time_settings ing" or whatever and it will cleanly fit alongside the older canadian system.

2 1

draft_v2
by A van Kessel 18 Jul '02

18 Jul '02

Inge wrote > >I would like to propose to keep the base document small, and define >protocol extensions in their own documents. This would preserve your >intention "to keep the document less imposing" as you wrote in the >specification. > > -Inge >gtp(a)lists.lysator.liu.se I could not agree more. Keep it small and never change existing commands. Base document: general structure + definitions + commands that (almost) everybody needs, and that are not likely to change. Possible extentions: tournament, rules, timing, scoring, regression. AvK .

1 0

New GTP version 2 draft
by Gunnar Farneb�ck 18 Jul '02

18 Jul '02

I've put up a new draft for GTP version 2 on the GTP web page, http://www.lysator.liu.se/~gunnar/gtp/ This is available in HTML, postscript, pdf, and LaTeX formats. The postscript and pdf versions are strongly recommended if you want to print it and probably also for online reading. The HTML version is passable but looks worse and has a couple of defects. If you want to quote or comment parts of the draft the LaTeX source is preferrable. This draft does not include every command that has been discussed on the list and definitely not all commands included in GNU Go. I have intentionally tried to limit the command set to something which is sufficient for the following purposes: 1. Playing games in a tournament setting. 2. Playing games on a server. 3. Basic regression testing. Notice in particular section 8 with comments about various design decisions and specification details. There are some missing sections in the draft, but the headings are there so you can see what is planned. I'm interested in feedback about: 1. Is there something which is really stupid in the design? 2. Is there some command or functionality which is urgently missing? 3. Are there any obvious errors in the specification? 4. Are there any spelling or other writing mistakes? (I'm not a native speaker.) The old draft is now considered obsolete. /Gunnar PS I'll be travelling a lot during the coming weeks, and may be without mail access for extended periods of time. DS

3 3

draft_v2
by A van Kessel 18 Jul '02

18 Jul '02

Gunnar wrote" |Adriaan wrote: |> Some comments on the 2nd gtp V2 draft: | |Thanks. I'll just add a few random responses at this time. Well, maybe | |> 3.2.1 move |> maybe "Resign" should be added as a valid move. | |Pass and resign are troublesome. I decided to include pass in the |vertex entity but sometimes it doesn't make any sense like in a list |of handicap stones. Resign on the other hand only really makes sense |as a response from genmove, so I added that explicitly as a |possibility for that command. | Maybe in the "basic types" section: vertex := %c%u move := vertex|pass|resign ( handicap_list would of course be vertex* ) That would solve it, IMO. Wanting resign allowed an argument for play, is a matter of symmetry. I'll seek help :-) | |> I think the PL[] and MN[] are (invisible) aspects |> of the board state. PL should be made explicit, |> MN is less important.) | |explicitly include color in the play and genmove commands. This is a |definitive decision for GTP version 2. I rest my case. |Absolutely not. The only sane way to communicate ko information is by |playing through the game so far. If superko is used it's also the only |way. For superko, I agree. For simple Ko there is only a need for it if a setup (AB[] AW[]) command is available. That seems to have been removed from the protocol(draft). But I agree, one can always work around it by stepping through the last move. | |> IMO, The regression subset is not needed (for general use) |> and should be consired an extension. | |You're underestimating the value of using GTP for regressions and the |potential for sharing well defined test suites between programmers. I |would have excluded this except for the fact that I consider it |extremely important. There is only a need for a standard if there is more than one program that implements it. A subset can be managed seperate from the core standard, but still care must be taken not to change the semantics needlessly. For very obvious entities (territory, evaluation) there will probably be shared semantics between implementations. For others (influence, rabbit-move-reasons) there will be not. |loadsgf is not in the core set for two reasons: | |1. GTP and SGF don't really fit very well. SGF has a complexity and | power of expression which isn't met by GTP. most implementations will need some SGF functionality. Whether this be in the core set, or in a separate unit is not important. |2. loadsgf requires the controller and the engine to have a common | filesystem. Commands are allowed to fail. |> I don't see much need for renaming the V.1 "help" command | |A matter of taste apparently. I think "help" is more ugly. It is not just about uglyness. It is about bloat. Should I Implement both commands ? Should I include a "version" field in my command table ? |I considered that alternative but I don't really like the "gen" |abbreviation. Does anyone else have an opinion on the naming of these |commands, or maybe a better proposal? To me it is very confusing, I have to reread both monographs every time to see which is which. Gen_free_handicap may be ugly, but it definitely breaks ambiguity. |> 6.3.3 play/genmove |Pass is already valid. (See definitions of vertex and move entities.) |Resign is an explicit possibility for genmove but would it really make |sense for play? Sorry, makes few sense. Protocol symmetry ? Maybe the engine could ring a bell and increment a counter when receiving a "resign" :-) |> To facilitate automated playing, a command to report dead stones |> could be added. eg: "list_dead_stones B" |This can be done with the not yet documented "final_status_list" |command. I prefer simple commands which do one thing. The final_status_list (what I've seen of it) was a kludge of subcommands. |What is the problem with these? If the engine wants to use move number |for some purpose it may change that state however it likes. I don't |see why the controller or the protocol should care. I am a state freak, I guess. |Player to move is a non-issue by design. For an engine, it might. for a GP program it is very important. |> [error] GMP uses a one-dimensional vertex |> coding scheme. 1 bit color + 9bits lineair addres, IIRC. |Yes, but it also associates this linear address with 2D coordinates |which are elsewhere used to define the fixed handicap placement. Not relevant. The topic is protocol, not program. |> [politics] Why mention IGS and not NNGS, KGS ? | You missed a :-) here. Maybe I omitted one. Yeah, I moved it to the protocol.Z part. Snipped nicely :-) |Actually I'd like to know which servers do use this convention and |whether there are some which don't. I only regularly use NNGS, so my |knowledge is rather limited here. | |Similarly I later have the comment "This fixed handicap placement is |compatible with the Go Modem Protocol and many go servers." This is |intentionally vague because I don't really know about IGS or other |servers than NNGS. Furthermore NNGS is only almost compatible. It |deviates, probably due to some obscure bug, for 2 and 3 handicap |stones on an 8x8 board. Any information about how other servers do |would be most welcome. People actually play 8x8 ? I'll give NNGS a peek. I think, communicating a vertex in %c%u format is pretty standard. Just stay with the hurd... paperware,IGS,NNGS: %c%u GMP: %u SGF: %c%c Kiseido: Propriety ? I am not aware of any free-handicap implementation. Just passing will do for most cases. But, the real reason for wanting it in the protocol, is cause of the HA[] in the game record, I guess. For the rest, the position can just be set up (by AB[],AW[], play) , and komi set seperately. |> 8.3.2 |> that others (than gnugo) will ever use them. |Not so. There already are other people using them. Sorry. Then you'll have to preserve their semantics in future versions :-[ |/Gunnar

1 0

gtp_v2draft
by A van Kessel 17 Jul '02

17 Jul '02

Some comments on the 2nd gtp V2 draft: [Textual] 1.6: reference implementation: s/considered as a/considered a/ [design,nitpicking] 2.8 Timing since, we have the possibility of "line numbers", I see no reason for the responses beiing sent back in the same order as the requests were received. There could be restriction on the order of *execution*, and maybe about the atomicy (sp?) of the responses. 2.13 private extensions. I like the xxx-yyy notation. Never liked hyphens, but I will in the future. :-) Of course, it could have been any character, like { . / : } [standards,nitpicking] 3.2.1 int. I don't like the idea of calling an unsigned "int". It is possibly confusing. Suggestion: "number" It is not important. 3.2.1 string. Again, a small departure from standard nomenclature. In most definitions, a string is allowed to contain whitespace. Suggestion: "word". 3.2.1 move maybe "Resign" should be added as a valid move. (in a subsequent section "Pass" was omitted) 4.1 Handicap. (maybe not so important) 4.1.2 is too big, IMO. There is no need to place a limit the number of handicap stones from the protocol per se (compare: the komi value in 6.3.2). With this amount of stones, the distinction between HA[] and AB[] becomes vague, anyway. Standardising the placement of fixed handicap stones is a good thing. 4.2 Time Handling Seems solid and simple. (Maybe for symmetry a parameter "main stones" could be added.) 5.1 State variables. (Summarizing previous email discussion: I think the PL[] and MN[] are (invisible) aspects of the board state. PL should be made explicit, MN is less important.) Also, for setting up positions, there could be added a provision for one or more "forbidden" ko-locations to be kept in the board state. I noticed the rulesystem-section has been removed. I rather liked this independent setting of tt-like rule elements. It looked clear and more workeable than a "package deal" Japanese/Chinese/Goe/Ing/Igs kind of approach (which involves more semantics). But, there is no hurry. Better wait for something good to come up, than including an ill-thought scheme. 6 Commands IMO, the core-set should be kept small. The timing commands should be moved to the tournament subset. IMO, The regression subset is not needed (for general use) and should be consired an extension. Strictly speaking, loadsgf is not needed in the core set, but can be allowed there, because it is general enough. Every implementation will need some kind of file loading, eventually. I don't see much need for renaming the V.1 "help" command into the ugly "list_commands". Semantics seem to have been tightened, but not changed. Handicap handling looks adequate. To me, place_free_handicap <--> set_free_handicap is confusing. My proposal: rename place_free_handicap into gen_free_handicap, which seems more in line with genmove, too. 6.3.3 play/genmove "pass" and "resign" should both be valid moves for both the "play" and "genmove" commands 6.3.4 To facilitate automated playing, a command to report dead stones could be added. eg: "list_dead_stones B" (IMO this should belong to the "core" set. ) Facility for "force_remove_dead_stones vertex*" seems not necessairy. final_xxxx, reg_genmove, showboard should be considered extensions, IMO. Maybe (instead of showboard) a command to query boardstate should be added. Every implementation will need one. loadsgf introcuces a lot of implied semantics. The boardstate is changed heavily by sgfload. SGF will change the MN-, PL- , KOlocation state in the engine, which were designed to be hidden in this GTP-draft. Things are even worse for the RU[] property... The real problem here is that clear_board is not guaranteed to reset all state. The simplest way out: sgfload is an extension. A work-around: require clear_board to reset *all* boardstate, including hidden state. Handicap See renaming proposal above. 8.2.11 [error] GMP uses a one-dimensional vertex coding scheme. 1 bit color + 9bits lineair addres, IIRC. [politics] Why mention IGS and not NNGS, KGS ? BTW, maybe IGS has a copyright on crippled protocols ... Just rename it protocol.Z and hide it somewhere on the internet! :-) :-) 8.3.1 Again; I liked the method in the previous draft: separate commands for scoring,korule,suicide, etc. 8.3.2 IMO these are extensions, since it is unlikely that others (than gnugo) will ever use them. 10 I sent this to my lawyer. That will keep him happy for a while ... Enjoy your vacation, etc 15Jul2002,AvK

2 1

version
by A van Kessel 12 Jul '02

12 Jul '02

So I have been reading a draft proposal ? :-) I think we agree, basically. A small, simple, textbased protocol is wat we want. It should not change with every version of gnugo. Apart from the syntax, the semantics should be clear. Minimalistic implemetations should be able to ignore anything they don't understand. I liked the section in the (draft ...)protocol, where the (not) initializing of enginevariables by the clear command was described. Then I realised, that having a bunch of invisible state variables (the were summed up neatly) , without being able to inspect or influence them, might be dangerous. That's why. As a basic command set: GMP is probably too small, and SGF is probaly too big. As for the PL[] command: there is another reason. Incremental programs may benefit from (;AB[........]AW[..........];PL[B] , because it enables them to delay the updating of internal structures. Instead of 100 incremental updates, they can do one massive rebuild, which is probably more efficient. The PL acts as a "commit", more or less. I remember a previous discussion on SGF where this came up. (was about why mixing setup and move properties in the same node was bad style, or even unwanted) Anyway, Have a nice weekend, AvK

1 0

gtp_use
by A van Kessel 12 Jul '02

12 Jul '02

Gunnar wrote: >Adriaan wrote: >> GTP. I am writing a nngs <--> gtp interface (unix: pipe+fork+exec) > >I assume you are aware that there already exists two go server to GTP >bridges, gnugoclient by me and gtpclient.c by Tristan Cazenave. How >does your program differ? Will it be publically available? Yes, I know. Have not checked Tristan's out though. There are mixed reasons for this, some personal or coincidental: 1) The last two years, I have done some hacking into NNGS, together with Nils Lohner. At the moment, this line of NNGS is more or less unused. It has become incredible stable though (I did perform replay of thousands of sgf-files via an automated testclient, without crash or resourceleaks. I hope Nils will soon releas this 1.1.14 version) I think a some_nngsclient<->NNGS<->some_bridge<->some_go_engine is a useable architecture for go programming. I don't like to do (G)UI stuff, so letting the nngs-client do that for me is just laziness. NNGS can be used as a independant middleman, maintaining the board(s), in a automated game or tournament. 2) I failed(for various reasons) in getting your pike-client up and running. 3) For my own project, I decided to use GTP as one of the interfaces. I did not want to complicate the program by adding a separate interface for command && control, add select/poll or threading. Now the protocolconvertor takes care of this. I have added some "bypass" functionality to manually send commands to the engine, via tell or yell. The bridge directs the responses back to tells or channel yells. (I'm planning on some Elisa functionality, too :-)) This is more or less independent of the normal game machinery. 4) chronic case of Not Invented Here - syndrome :-) I might release the source GPL. At first, it should be useable. At the moment, it accepts and plays a game, but does not know how to end. It does not respond well yet to crashes at either side of the connection. >This is addressed in my new specification draft. The relevant section > >| Engines are allowed to use private extensions without a dash in the >| name, but then they do it at their own risk and must be prepared to > Good. >> 2) gnugo should *not* pollute the existing namespace with redundant >> commands. eg: genmove_black is equivalent to "genmove b". this >> is protocolbloat to avoid. > >There is no "genmove" command in GNU Go. You may be thinking of Exactly. Instead of the gtp version 1 command "genmove" *four* extentions to the commandset were implemented. For perfectly valid reasons, of course. >In version two of the protocol genmove_black and genmove_white will be >replaced by a single genmove command. There will also be a command >reg_genmove for regression purposes. Good. I don't object to extensions. But basic functions should be mapped to the standard command set, IMHO. > >> 3) gnugo extends the error messages with descriptive text, eg: >> out_of_range: point d33 is outside the board. > >I'd like a concrete (and real) example to comment on that. I could not get a runnable version og gnugo here at work. Just some visual inspection of the source(3.2 play_gtp.[ch] ): gtp_failure(id, "komi not a float"); gtp_failure(id, "handicap not an integer"); Should have been "invalid_argument" ? there are more of these. I know this seems like nitpicking. But bloat in the responses will make it increasingly hard for the driverprograms. A two level message ala "404: not gound", or "invalid_argument : some extra text" would combine the best of both worlds. > >> 4) some features still seem to bi missing : the equivalents of >> sgf MN, PL , some timecontrol. >How would MN be useful? PL follows implicitly from the issued genmove >commands. Time control commands are included in the new draft. > At the moment they both represent invisible state in the engine. Someone may want to evaluate territory or the status of groups without generating a move. Evaluation is impossible without PL. Currently, the only way to influence the PL variable is by adding the correct player last. That is not exactly an elegant solution. I dont know if MN could play any role in evaluation. It could be necessary for debugging purposes. >> 5) at the moment, the protocol is practically stateless. >> Maybe a "game" or "session" layer should be added in a > >To solve what problems? > >/Gunnar Not yet. I agree, we should not design a "paper" protocol for future use only. But, in the future an engine might want to perform it's own passing, scoring, removal of dead stones, etc. Just like doing it's own timecontrol. Or, at least: be aware of it. I realise it is hard to maintain an "independent" protocol, with gnugo beiing virtually the only user. A design-by-committee- approach is not wanted. What is needed is stability: the basic commandset should work, regardless of version or age. Extensions are fine, and very useful for development. But they should not replace standard commands. Esperanto does not need dialects. BTW, in the standard definition paper, it is very hard for me (as a non-native reader) to determine the "sign" of the "prisoners" response. Are black prisoners "taken by black", or "colored black" (taken by white) ? Happy hacking, AvK

2 1

gtp-use
by A van Kessel 12 Jul '02

12 Jul '02

Jules: > I was just wondering how wide spread the use of GTP currently is? So do I. Personally, I am using gnugo as a "reference implementation" for GTP. I am writing a nngs <--> gtp interface (unix: pipe+fork+exec) so that i can use nngs as primary interface for go-programs. Since GMP over a network connection is silly, I think GTP is a logical choice. Line oriented protocols are simple to construct and debug. I would have liked a more smtp/nntp-like protocol, with status/error-numbers instead of the "?number textstring" lines, but the current format will do. There are two things, I would like to be changed in gtp: 1) a reserved namespace for "local" additions, eg all commands starting with [xyz] are reserved for local command extension. 2) gnugo should *not* pollute the existing namespace with redundant commands. eg: genmove_black is equivalent to "genmove b". this is protocolbloat to avoid. 3) gnugo extends the error messages with descriptive text, eg: out_of_range: point d33 is outside the board. 4) some features still seem to bi missing : the equivalents of sgf MN, PL , some timecontrol. 5) at the moment, the protocol is practically stateless. this allows for the goprogram to accept and generate moves , without having a notion of a game (or gamestate). Maybe a "game" or "session" layer should be added in a next version of the protocol. But: the current protocol enabels a program to functional with only 5-10 gtp commands implemented, which allows it to focus on making moves instead of changing pixels on a screen ... AvK

2 1

Protocol use
by Churchill, Julian 12 Jul '02

12 Jul '02

Hi, I was just wondering how wide spread the use of GTP currently is? I have used the protocol for my own Go program specfically so I could leave the program playing against other programs over the weekend when I'm out of the office, but at the moment the only program I can find that uses GTP is GNUGo. So are there any other GTP implementors out there or is this going to be a one boat show? Personally I have every intention of using the protocol and leaving it in ready for a public release, as the preferred comms method, and I find it very useful for automated regression testing (ala GNUGo) and as an expert interface to the program as an alternative to simple text menus (for just playing Go). Cheers, Jules

2 1

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 July 2002