gtp

gtp@lists.lysator.liu.se

164 discussions

Goals of GTP?
by William M. Shubert 11 Aug '01

11 Aug '01

Hello everybody. One thing that I haven't seen discussed yet is the exact goals of GTP. It probably seems obvious to everybody what these goals are, but perhaps not everybody's view is exactly the same, so I think it would be good if we could put together a goals document that we can all agree on. Then when we discuss features and commands, we can always refer back to the goals document and use it to help us decide whether or not these commands fit our goals well. Maybe we could even put the goals document on the "lists.lysator.liu.se" web site? In any case, it seems like it would be nice to have a place where more or less permanent documents that we have already agreed on are kept. Anyway, here's my first attempt at a goals document. It's a combination of what I think are goals and what I have seen discussed here in the past week or so. ********************************************************************* GTP Goals Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement and debug; all ASCII. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs. 3. There must be a minimal command set that is exactly enough commands to play head to head, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. ********************************************************************* So what does everybody think? Anything I left out/shouldn't have included/got wrong? PS - Hopefully this message will make it to the mailing list in plain text - I think my mailer is set up properly, but I may have made a mistake that will make it send HTML mail. My apologies if this happens, I'll make sure to fix it if it does. -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

6 7

Terminology
by Phil 11 Aug '01

11 Aug '01

I am drafting up a standards documents and have a terminology question for the group. The GNU description of GTP calls party A the arbiter or relay, and party B the engine. To simplify the terminology I want to call party A the controller, where the controller can be a GUI, an arbiter or relay. Sound reasonable?

1 0

RE: [gtp] Goals of GTP?
by Cabrera, Alan 10 Aug '01

10 Aug '01

Concerning Part II, item 1. Do you plan on players being able to send comments back and forth? If so, then maybe UTF-8 may be better. Alan -----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Friday, August 10, 2001 10:40 AM To: GTP Mailing List Subject: [gtp] Goals of GTP? Hello everybody. One thing that I haven't seen discussed yet is the exact goals of GTP. It probably seems obvious to everybody what these goals are, but perhaps not everybody's view is exactly the same, so I think it would be good if we could put together a goals document that we can all agree on. Then when we discuss features and commands, we can always refer back to the goals document and use it to help us decide whether or not these commands fit our goals well. Maybe we could even put the goals document on the "lists.lysator.liu.se" web site? In any case, it seems like it would be nice to have a place where more or less permanent documents that we have already agreed on are kept. Anyway, here's my first attempt at a goals document. It's a combination of what I think are goals and what I have seen discussed here in the past week or so. ********************************************************************* GTP Goals Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement and debug; all ASCII. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs. 3. There must be a minimal command set that is exactly enough commands to play head to head, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. ********************************************************************* So what does everybody think? Anything I left out/shouldn't have included/got wrong? PS - Hopefully this message will make it to the mailing list in plain text - I think my mailer is set up properly, but I may have made a mistake that will make it send HTML mail. My apologies if this happens, I'll make sure to fix it if it does. -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/> _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

1 0

Minimal GTP command set
by Phil 09 Aug '01

09 Aug '01

So far the minimal GTP command set includes: Boardsize Komi Fixed_Handicap White Black Genmove_Black Genmove_White Undo (* provisional for now) Quit What else?

6 13

RE: [gtp] GTP: making the command set smaller
by Peter.Smith＠Smallworld.co.uk 09 Aug '01

09 Aug '01

> There need never be a command to load an SFG file, because that can > and should be implemented by interface software. As long as there is > some way to set up the position or game, we are ok. > > Don > As I understand it GTP as GnuGo use it currently contains a load SGF file command which means the engine has to understand SGF. So it is reasonable to consider setting things like boardsize by sending the SGF token SZ[] to do it rather than having an explicit GTP command. But when I get to the point of needing to write GTP handling I'll be happy to run with whatever the consensus is providing there's enough functionality, and there is a way to connect GTP and GMP together. Peter. > From: Peter.Smith(a)Smallworld.co.uk > > I'm some way off doing anything with GTP yet so this is > rather commenting > from the sidelines. > > GTP has a command to load a SGF file? Suppose GTP had a > command to pass SGF > elements to an engine like "KM[5.5]" ? Would that remove > the need to have > certain commands as you could pass them as the SGF equivalent? > > I think having a GTP to GMP bridge will be important. > Otherwise if I write > a Go program having a GTP interface isn't going to be > enough to play > matches. Should GTP have equivalents for the main GMP commands? > > Peter Smith. > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

GTP: making the command set smaller
by Peter.Smith＠Smallworld.co.uk 09 Aug '01

09 Aug '01

I'm some way off doing anything with GTP yet so this is rather commenting from the sidelines. GTP has a command to load a SGF file? Suppose GTP had a command to pass SGF elements to an engine like "KM[5.5]" ? Would that remove the need to have certain commands as you could pass them as the SGF equivalent? I think having a GTP to GMP bridge will be important. Otherwise if I write a Go program having a GTP interface isn't going to be enough to play matches. Should GTP have equivalents for the main GMP commands? Peter Smith.

2 1

Re: [gtp] Random thoughts
by Dave Denholm 06 Aug '01

06 Aug '01

Daniel Bump <bump(a)match.Stanford.EDU> writes: > > That different systems tend to use different newline conventions is a > > problem that must be addressed by the standard. Personally I prefer > > the unix convention of a single LF but it probably would invite > > problems not to accept the presence of CR. My proposal is that all > > occurences of CR are simply ignored and that an LF defines a > > newline. This would work with systems using only LF or CRLF but > > obviously not with systems using only CR. Would this be a > > (significant) problem? Are there any better solutions? I'd really > > appreciate input on this point. > > Are there any other conventions besides the DOS and Unix ones? ISTR that Mac-os uses CR only ..? But just because a machine uses that for text files doesn't necessarily mean that convention has to work across GTP. Oh : BTW, it does mean that things like \n should not be used in GTP code, since that expands to something platform-specific, and on a Mac gives CR. dd > > It seems to me that this solution (discard CR) is best. > But it means that applications have to be coded somewhat > carefully. > > Dan > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

Re: computer-go: gnugoclient 2.0
by Daniel Bump 05 Aug '01

05 Aug '01

I'm cross-posting this to the computer and gtp lists. Perhaps that is the best thing to do until the gtp list gets critical mass. Heikki wrote: > I do agree that it is important to specify the behaviour of the undo command > now, to avoid different implementations. But I also agree that the command > is of limited use, probably only in human-computer games, which is but one > use for the protocol. Thus I do not agree that "undo" must belong to the > minimal set of commands all programs must implement. Let me point out some possibilities that require undo. An undo command opens up a world of possibilities. For example we could create a meta-machine that asks GNU Go for its top 2 or 3 moves, tries them, evalutes the board and then chooses the one with the top score. My guess is that it will be slow but immediately stronger than GNU Go. More ambitiously, make a metamachine that does limited global search. Slow, but computers don't get bored if the game is slow. One could code this in a couple of hours using perl and the gtp. But it would require undo. One could do experiments involving multiple engines along the lines of Althofer's n-Hirns. (I don't think the exact n-Hirn idea that was successful in Chess will work immediately in Go, though Althofer has been trying it, but there are possibilities of doing something using multiple engines.) Dan

2 4

Two synonyms
by Daniel Bump 05 Aug '01

05 Aug '01

I want to add synonyms for two gtp commands in GNU Go 2.7.248. I don't want to remove the old names but I prefer the name "captures" to "prisoners" and "new_score" should be called "estimate_score". Dan

4 4

Random thoughts
by Gunnar Farneb�ck 05 Aug '01

05 Aug '01

Here's an unstructured list of some things that need to be addressed in a standards document. More will follow later. 1. Private extensions. Obviously the protocol is easy to extend just by adding new commands. To bring some order I suggest the following: Standard commands are limited to use the characters [a-z_0-9] and must start with a character in [a-z], i.e. only lower case English letters, underscore, and digits, starting with a lower case letter. Private commands are limited to the same characters plus hyphen and are suggested to be of the form "x-y" where "x" is a program specific prefix, e.g. gg for GNU Go and "y" is the rest of the command name. One example of a private command could be "gg-owl_attack". I don't think we need to keep any official list of prefixes. These commands should be program-specific anyway. 2. Newline conventions That different systems tend to use different newline conventions is a problem that must be addressed by the standard. Personally I prefer the unix convention of a single LF but it probably would invite problems not to accept the presence of CR. My proposal is that all occurences of CR are simply ignored and that an LF defines a newline. This would work with systems using only LF or CRLF but obviously not with systems using only CR. Would this be a (significant) problem? Are there any better solutions? I'd really appreciate input on this point. 3. Case sensitivity Should the protocol in general be case sensitive or not? 4. Unknown command versus unimplemented command. I don't think it's useful to distinguish between unknown commands and unimplemented commands. Thus a program should respond with "?[id] unknown command" to everything it doesn't recognize or knows it can't handle. Currently GNU Go does like this: | 1 fds | ?1 unknown command: 'fds' I think we should skip everything following "unknown command". /Gunnar

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