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 wrote:
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.
Good idea.
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.
Yes, I can see to this. Also reference/sample code should be made available there. I won't be able to set this up until after August 19, however, since I'll leave for a mountain hike tomorrow.
- Usable to play games vs. other programs head to head.
I assume this leaves it open whether some kind of arbiter is involved or not.
- Possible to create bridges that let GMP programs play head to head
vs. GTP programs.
There's some risk for overinterpretation here. This does not say that it should be possible to translate any GTP command to a GMP equivalent.
- 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.
As I've said before I think a few commands of an administrative character should also be required, like name, version, and protocol_version.
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.
- 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.
In addition to this I think programs for connection to servers are fairly valuable. Gnugoclient exists for connection to NNGS and compatible servers. I assume you have some interest in providing something similar for KGS.
So what does everybody think? Anything I left out/shouldn't have included/got wrong?
At the first look it seems fairly good.
/Gunnar
Hi William,
This is a good start. You are right that not everybody is seeing this the same. That's to be expected and part of the process. I agree on building such a guideline document first as a focal point.
I'm going to suggest some changes to your document, based on my own "vision" of what I think GTP should be. Please let me explain my motivation first, and then people can critique this:
First of all, I personally am not very interest in a project that simply reimplements GMP (but uses text instead of binary codes.) In several posts I have noticed that people have not been very imaginative (and I'm not saying this to offend anyone) about what they expect out of GTP.
A careful reading of the posts, reveals clearly that many are stuck in the GMP mode which is this, "Carefully set up your engines beforehand to get all the playing options right and compatible, then let GTP pass moves back and forth."
There is nothing wrong with this model, but we already have this in GMP, right? This is not a step forward.
So in view of these things, I would suggest the following modification to your excellent first pass document:
********************************************************************* 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. 4. Usable to write full featured user interfaces.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
1. Simple for clients to implement and debug; all ASCII. The standard GTP command set should be small (but not minimal.)
2. You can implement any subset of the "standard set" you wish, with the caveat that you may reduce the functionality of software than needs the unimplemented commands. The client must always return "not_implemented" in these cases.
3. Interface software, should be designed to gracefully accept the lack of not implemented features.
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. A general purpose user interface that excercises all the features of the standard set we design. (It shouldn't crash if a feature has not been implemented.)
2. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP).
3. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. The arbiter should know how to properly score the game.
4. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other.
5. If feasible, a GMP to GTP wrapper. This is really a program that "converts" a GMP program to a GTP program, but of course can only represent a subset of the command set. With some creativity, we might be able to implement MOST of the command set by playing tricks like killing and restarting the engine with the correct options and so forth.
*********************************************************************
I left out a couple of things that you had in the document:
2. Possible to create bridges that let GMP programs play head to head vs. GTP programs.
Should that be a constrain? I don't want to be constrained by this even though I agree we should do this if it's possible (which I'm sure it is.)
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.
I've thought a lot about this the last few weeks. I don't really see any need to define a bare minimal set. The programmers will implement anything they want anyway, we cannot or should not enforce this.
"undo" is a good example. I don't care if someone chooses not to implement undo, the interface can simply report to the end user, in a graceful manner, that the engine doesn't support undo!
It's a lot better, in my opinion, to keep the whole set small and simple so that people are encouraged to do the whole set. As one person pointed out, we don't want to be stingy about commands like "version", since this is so trivial to implement that programmers will do it as a matter of course.
Don
From: "William M. Shubert" wms@igoweb.org
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@igoweb.org) mailto:wms@igoweb.org http://www.igoweb.org/~wms/ http://igoweb.org/%7Ewms/
_______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
On Fri, Aug 10, 2001 at 12:04:02PM -0400, Don Dailey wrote:
- 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.
I've thought a lot about this the last few weeks. I don't really see any need to define a bare minimal set. The programmers will implement anything they want anyway, we cannot or should not enforce this.
This might not be as good an approach as you think.
It's my understanding (based on an explanation from David Fotland at this year's "21st Century Cup" computer tournament at the AGA) that the "specify everything, people will choose a subset anyway" approach has already been tried in Go protocols, with disappointing results. Implementing the complete Go Modem Protocol is enough of a hassle that some tournament (which he identified, but which I don't remember) encouraged people to implement a subset. That subset then took on a life of its own, and many programs implemented it. However, not all did. In particular, the third place finisher at the tournament, Wulu, had interoperability problems apparently -- again from David Fotland's description -- because it implemented the full spec instead.
(I'm not 100% sure that I understood the story correctly, because my program also attempted to conform to the full GMP, and my only interoperability problems were traceable to bugs in my code. But that doesn't necessarily contradict the story, since Wulu's problems only showed up when playing one color, and against a different (stronger:-) set of opponents than my program had. And anyway, whether or not it was at the root of Wulu's problems this year, it has apparently been a substantial problem in earlier tournaments.)
Also, it's been my experience that "it's too simple" is not the most common complaint that informed people have about a protocol once it's actually in use; and that furthermore, when excessive simplicity is the problem, it's often relatively easy to fix it in version N+1. Problems like "it's not interoperable" or "it's too unreliable" are common and harder to fix. Simplicity can help a lot in avoiding those problems.
"undo" is a good example. I don't care if someone chooses not to implement undo, the interface can simply report to the end user, in a graceful manner, that the engine doesn't support undo!
It's a lot better, in my opinion, to keep the whole set small and simple so that people are encouraged to do the whole set. As one person pointed out, we don't want to be stingy about commands like "version", since this is so trivial to implement that programmers will do it as a matter of course.
If the minimal conforming implementation is so simple that everyone implements it, that's good. Among other good things, the risk of incompatibility scenarios along the lines of the GMP problem above goes away. But to encourage that happy outcome to happen, I think it's wise to make the minimal conforming implementation very, very simple.
From: William Harold Newman william.newman@airmail.net
On Fri, Aug 10, 2001 at 12:04:02PM -0400, Don Dailey wrote:
- 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.
I've thought a lot about this the last few weeks. I don't really see any need to define a bare minimal set. The programmers will implement anything they want anyway, we cannot or should not enforce this.
This might not be as good an approach as you think.
Ok, you have convinced me.
We have gone back and forth on this as a group which is why I relaxed my opinion of this. A bunch of people here don't think we need anything more than about 5 commands and seem to even resist it.
I think the common sense solution is to define a small, but COMPLETE set and encourage people to implement it in full. The point I was making is just that we cannot really stop people from being lazy or (too busy) to implement the whole set if they discover that they can do something they need to do with only 4 commands.
In my opinion, the only thing that will really make this work and make a protocol really successful is to build some killer software that needs the full set. No one is going to really give a hoot unless a killer interface motivates them to WANT to be compatible. If they have to ask, "why not just stick with GMP", then we are wasting our time.
So I agree, we should probably talk about this in terms of only 1 full set, you program either conforms to this particular standard, or it does not. The standard won't be too burdensome to implement, and we should provide a unit test utility that will determine if a program is fully conforming or not. This probably would motivate programmers to implement it, having a nice reference tool like this.
Don
It's my understanding (based on an explanation from David Fotland at this year's "21st Century Cup" computer tournament at the AGA) that the "specify everything, people will choose a subset anyway" approach has already been tried in Go protocols, with disappointing results. Implementing the complete Go Modem Protocol is enough of a hassle that some tournament (which he identified, but which I don't remember) encouraged people to implement a subset. That subset then took on a life of its own, and many programs implemented it. However, not all did. In particular, the third place finisher at the tournament, Wulu, had interoperability problems apparently -- again from David Fotland's description -- because it implemented the full spec instead.
(I'm not 100% sure that I understood the story correctly, because my program also attempted to conform to the full GMP, and my only interoperability problems were traceable to bugs in my code. But that doesn't necessarily contradict the story, since Wulu's problems only showed up when playing one color, and against a different (stronger:-) set of opponents than my program had. And anyway, whether or not it was at the root of Wulu's problems this year, it has apparently been a substantial problem in earlier tournaments.)
Also, it's been my experience that "it's too simple" is not the most common complaint that informed people have about a protocol once it's actually in use; and that furthermore, when excessive simplicity is the problem, it's often relatively easy to fix it in version N+1. Problems like "it's not interoperable" or "it's too unreliable" are common and harder to fix. Simplicity can help a lot in avoiding those problems.
"undo" is a good example. I don't care if someone chooses not to implement undo, the interface can simply report to the end user, in a graceful manner, that the engine doesn't support undo!
It's a lot better, in my opinion, to keep the whole set small and simple so that people are encouraged to do the whole set. As one person pointed out, we don't want to be stingy about commands like "version", since this is so trivial to implement that programmers will do it as a matter of course.
If the minimal conforming implementation is so simple that everyone implements it, that's good. Among other good things, the risk of incompatibility scenarios along the lines of the GMP problem above goes away. But to encourage that happy outcome to happen, I think it's wise to make the minimal conforming implementation very, very simple.
-- William Harold Newman william.newman@airmail.net "Be liberal in what you accept, and conservative in what you send." -- Jon Postel, RFC 1122 PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
On Fri, Aug 10, 2001 at 07:39:46AM -0700, William M. Shubert wrote: [a proposed Goals/Requirements document]
I have 4 suggestions.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
- Simple to implement and debug; all ASCII.
- Possible to create bridges that let GMP programs play head to head vs. GTP programs.
- 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.
-- suggestion 1 --
Gunnar suggested three more commands: name, version, and protocol version. I'm not sure that all three are needed, but I think that protocol version, at least, is a sufficiently useful and simple thing that it belongs in essentially every protocol. (This seems to be the consensus of the RFCs I've seen.)
-- suggestion 2 --
I suggest one more command: out-of-band text. This could be useful for at least the following: * as a low-tech ("poor man's") replacement for Gunnar's "name" and "version" commands, plus some others like "event" * as a poor man's way of handling error conditions (Send a human-readable message as out of band text, then close the connection.) * as a poor man's way of handling stuff like kibitzing and direct opponent-to-opponent communication that occurs on servers E.g. out_of_band server round 1 white=plodder black=aya out_of_band client plod-2.0.520, 2001-08-10, rng seed 5824c103 out_of_band client error: can't understand GTP version 9, giving up out_of_band server *FATAL* illegal move 11a out_of_band server kibitz from "smith616" "g3 rahter tricky"
It is also very easy to implement an out-of-band text command, both in a minimal server and in a minimal client. A minimal server can just echo it. (I rather hope that "just echo it" can be a conforming server default implementation for nearly all commands.) A minimal client can either ignore it (if it's really really hard core minimal) or echo it to the screen/logfile/whatever. The only complexity I can see is how you delimit the text, but if you take care in specifying that (e.g., in a line-oriented protocol, requiring escape sequences for any line-breaking characters) you can allow arbitrary messages without increasing the minimal complexity of conforming servers and clients.
(Some might say that an out-of-band text command is also useful as a way of implementing some kinds of extensions, but IMHO that's more of an attractive nuisance than a feature. The first-step-up-from-minimal protocol should provide a way to add extensions, and it should be cleaner, e.g. defining a standard way for one implementation's extensions to avoid colliding with other implementations' extensions, and defining a standard way for an extension to say "It's safe to ignore me if you don't understand me.")
-- suggestion 3 --
I'm not sure that "no server" is a required case. The complexities of choosing a server and socket (that you'll listen on and your opponent will connect to, or vice versa), of communicating the server and socket to your opponent, and of making conforming client programs smart enough to handle sockets not only the connecting direction but also in the listening direction aren't overwhelming, but they're noticeable. Maybe we could dodge those complexities.
I'll renominate the target simple cases that I suggested on the main computer-go mailing list: * a minimal client playing where the rules, and everything else, are known by an outside channel. (E.g. in a computer Go tournament where you learned the rules, time controls, and so forth from the tournament organizer.) * a minimal server which doesn't know anything about the rules or anything else, basically just echoing stuff to and fro (and possibly recording what it echoes so that that some smarter entity can check it for legality later in case of dispute) I think it's very desirable that these be implementable very, very simply.
Then, if the minimal server can be done in e.g. two dozen lines of no-more-obfuscated-than-the-typical-Programming-Perl-example Perl, I think support for direct client-to-client communication could be unnecessary.
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.
- An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP).
- 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?
- A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other.
-- suggestion 4 --
Regarding point 2 here: It would be good to provide a reference implementation of an arbiter which knows how to score a game, but as above, I really think it's even more important to support a trivial server which isn't an arbiter at all, but is as dumb as a box of rocks. Then ideally there should be at least two reference implementations. One reference implementation should be trivially stupid and simple and should take only 2 minutes to understand. The other can be reasonably smart and is capable of scoring, complaining about clients which don't conform to the protocol, and possibly doing other clever useful things as well.
Where can I find information on the fixed_handicap command? GNU Go doesn't implement such a command.
Thanks, Phil
Where can I find information on the fixed_handicap command? GNU Go doesn't implement such a command.
Yes it does. You can get a list of all commands GNU Go implements by running the gtp command help.
Set handicap stones by runnning (say)
fixed_handicap 3
then you can run showboard to see what has been done. BTW showboard sends output to stderr not stdout.
Dan
-
Daniel Bump -
Don Dailey -
Gunnar Farneb�ck -
Phil -
William Harold Newman -
William M. Shubert