Dear list,
first of all, my intention is by any means to hurt anyone's feeling nor to start any flame war.
This said, IMHO i think this spec is a little shortsighted ...
Here are at least three reasons why :
1- the BOARD command should accept to create rectangular gobans... the question is why restrict it to square only ? I understand gtp is designed to enable testing on software programs ? then please let the possibility to foster some diversity... It would be good to see gnugo on a 4x7 board for instance :-)
2- "Boards larger than 25x25 are not supported by the protocol." Why ? Is it so complex to use another coordinate systems as 1,1 instead of A1 ? I know SGF has the same limitations, but why imposing such limitations ? is that another heresy to think about a 51x53 board ? played by two softwares for instance ? OK i'm definitely an heretic... for now :-)
3- the last but not the least concerns the time_settings. And here it's a special request : why not offer the possibility to set different time settings for each player ? again i think it would be fun to afford more time for gnugo than for myself. That would put more pressure on me...
ok i talk a lot about gnugo but i understand that the spec is tightly bound to gnugo or the opposite ...
Hope that i'm not off topic.
Best regards. Rodrigue.
Rodrigue wrote:
1- the BOARD command should accept to create rectangular gobans... the question is why restrict it to square only ? I understand gtp is designed to enable testing on software programs ? then please let the possibility to foster some diversity...
I considered including rectangular boards but I couldn't convince myself that it would be worth the extra burden on the protocol, however small it may seem.
It would be good to see gnugo on a 4x7 board for instance :-)
The interface issues are the least of worries in this case. There simply aren't any provisions in the code to handle rectangular boards and it would require major work to add it.
2- "Boards larger than 25x25 are not supported by the protocol." Why?
To allow using the most convenient coordinate specification that was already in regular use, of course.
Is it so complex to use another coordinate systems as 1,1 instead of A1?
In some ways it's even easier to to use two integers, in other ways it's a much worse choice. But let's face reality: only a very tiny fraction of go games is played on any other boards than 19x19, 9x9, and 13x13. 7x7 has seen some interest during the evolution of Monte-Carlo programs and very occasional 21x21 games can be seen on the go servers. Anything else is rare.
I could have included support for rectangular boards, huge boards, 3D boards, or go on general graphs but it's not worth the overhead having standard features that neither engine writers nor GUI writers have much interest in supporting.
I know SGF has the same limitations, but why imposing such limitations?
In the sgf case the limit is 52x52 in order to keep the file size small while retaining a reasonably simple encoding.
is that another heresy to think about a 51x53 board ? played by two softwares for instance ? OK i'm definitely an heretic... for now :-)
For anyone who wants it's quite easy to add private extensions for rectangular boards, huge boards, etc. Feel free.
3- the last but not the least concerns the time_settings. And here it's a special request : why not offer the possibility to set different time settings for each player ?
Time management is a can of worms. It would be useful to have quite a few more time systems (Japanese byo-yomi, Fisher time, ...) but it would also increase the burden on the programmers to try to implement support for a wide variety of time systems.
That said I don't find asymmetric time settings (within the same system) unreasonable but again not quite worth the trouble.
again i think it would be fun to afford more time for gnugo than for myself. That would put more pressure on me...
In the GNU Go case it would work to cheat and immediately report less time left than the time settings indicated but I can't recommend it as a general workaround. :-)
ok i talk a lot about gnugo but i understand that the spec is tightly bound to gnugo or the opposite ...
It was originally designed for the needs of GNU Go but seems to have been reasonably useful for other engines too. There are certainly a number of limitations imposed by the protocol but I don't think anyone else has brought up board size limitations as a major concern before.
Hope that i'm not off topic.
You couldn't get much more on topic. :-)
/Gunnar
Dear list,
here is a very long mail to Gunnar and i hope the contents is not just a pile of crap ... When rereading it, however, i feel i should have shut it in the first place. if you have time to waste... :-) (Sorry for the inconvenience, I think it shall be the last one on the subject)
GTPv2 WAS GOOD
i think GTP was a good thing back in the change of the millenium because it was giving more. GMP (Go Modem Protocol) was ruling and Gnugo brought a set of new possibilities that could be used by interfaces.
The spec was written and we hardly hear about GMP anymore. GTP is now a de facto standard. People like when they are given more.
WHAT'S THE SITUATION NOW
As GTP has been around for many years, even if published in draft, it is shaping either new go programs or UI programs.
GTP is a bottom-up specification that was spawn first to enable Gnugo to communicate with UI. In this respect, GTP should have been Gnugo Text Protocol... But altruistically, GTP manages to become Go Text Protocol. That move seems to provide all other would-be go programs a common base to work with.
We could still see the struggle between the two (go text protocol and gnugo text protocol) in sections 1.1 and 1.5 : 1.1 "The intention of GTP is to provide a flexible and easy to implement communication protocol for go programs ..." 1.5 "The reference implementation for GTP version 2 is GNU Go version 3.4 ..."
What is happening is that the implementation decisions that were made for Gnugo made their ways (naturally) in the spec thus shaping all the future go programs and UI programs to respect the Gnugo decisions. I consider this is a serious matter.
I don't say those decisions were bad. I say they are constraining. Maybe someone (say me) will ask for more and the spec will tell him : make your extension or do your silly stuff elsewhere. I think that the spec should now encompass a broader scheme.
When you say : "I could have included support for rectangular boards, huge boards, 3D boards, or go on general graphs but it's not worth the overhead having standard features that neither engine writers nor GUI writers have much interest in supporting.", I understand that GTP is Gnugo Text Protocol. I understand that Gnugo is the only one and always will be. I understand that all UI will have to be the same. I understand uniformity.
Don says : "Your view of what the protocol should be like includes a lot of things rarely used in practice." Yeah that's true. Should they never be implemented by any fool like me ? I think that if I don't ask for this features they will never ever be implemented by anyone. I would never ask any human to play silly games like 13x9. That would probably waste his/her time. And there is no such physical board on the loose. But when i play a software, i kind of like to ask it silly things. (you should study the real go games of pros instead you'll improve. yeah i know)
I'm asking for more. :-)
Perhaps because i'm a weak player, 10k on Igs, i talk about silly things like rectangular or giant board or asymmetric time settings. I first used Gnugo with Cgoban by Bill Shubert. Then i used Ggo by Peter Strempel. And from time to time i try other (free) interfaces : Jago, Gogui, etc. and still with Gnugo since it's the only free decent go program out there. What was not my surprise to see one day, gnugo resigned ! i said to myself 'wow nice feature! why ggo doesnt have it ?' i think it's because it had appeared in the draft at some time (response to genmove is vertex or "resign") and no renumbering had occured so that only new implementations had the feature ...
I think go programs can improve. I think UI can improve. I think a broader spec could do just that.
I think the umbilical cord should be cut between Gnugo and GTP. GTP should live by iself.
Gnugo should not be the reference implementation of GTP but an example implementation.
OH MAN YOU COULD SILLY-TALK, BUT WHAT DO YOU PROPOSE ?
I think it's time for GTP to adopt a top-down approach of what should a go program do, not just Gnugo. In fact, even Gnugo had evolved trying regularly to push surely the better in the spec. I think it's bad practice.
I totally approve Don's remarks concerning 'total backwards compatibility'.
I agree that GTP should provide a flexible communication protocol for go programs. But the spec should not limit itself to implementation constraints. It should be a diving suit for the happy programmer who'd like to throw himself in the (miry?) pool of creation. (i should ask my psy about that metaphor. should have a Freudian meaning of some kind)
It's the freedom of the implementor to limit the compliance to the specification. And the specification should provide a means for the go program to say what have been implemented. Who benefits ? The user because he runs the risk to have more options than the obvious and legitimate 9x9, 13x13 or 19x19...
I don't like much the idea of an extension because it corners what could be an interesting evolution of the spec in a single program or implementation. And perhaps someone will reinvent the same wheel again in its program over and over. Still, it seems to be a necessity somehow.
Then i suggest : - Freeze GTP v2 now ! tag everything as '[V2.x]' for instance. I think it is important to track the spec changes effectively. GTPv2 should be the core spec. Every go program should understand GTPv2. It's important that the commands created remain the same. Here we deal with 90% of today needs. - now let's tackle the go programs of the future : 1- a go program should be able to publish its capabilities. That way a UI program can query the caps and propose the user more choices. This is not the list of commands. A capability is the value enforced by a program on a featured aspect. Example I: for CasualGo (a would be go program) it could be: accept_square_board : true square_board_size_limits : 3-19 accept_rectangular_board : false accept_asymmetric_time_settings : false accept_tournament_minute_timer : false accept_undo : false
the initial query and response could be : casualgo> get_capabilities = square_board_size_limits accept_rectangular_board accept_asymmetric_time_settings accept_square_board accept_tournament_minute_timer accept_undo\n\n
then getting a capability could be : anygo> get_capability square_board_size_limits = 3-19\n\n
Example II : suppose BetterGo has the following: accept_square_board: true square_board_limits : 1- (oh my! who ever thought to play a 1x1 game? black always wins! :-) ) accept_rectangular_board : true rectangular_board_limits : 1- (oh no! he has lost it! a 1x19 game? how do you count that???) accept_asymmetric_time_settings : true accept_tournament_minute_timer : true accept_undo : true undo_limit : none (please, where can i find BetterGo? is it free?)
then setting asymmetric timer could be : bettergo> black_time_settings 10 10 25 = \n\n bettergo> white_time_settings 5 5 25 = \n\n
etc. Maybe the capabilities should be suffixed by _ro if they're read-only.
2- the spec shall live and every addition should tagged with the new number of the spec. A minor and a major. The spec should be proud to accept or ponder adding new stuff. It's its natural course : evolution. Perhaps the spec wants a lifting too : in the documentation, the commands are neatly categorized in admin, setup, core play, tournament, regression and debug. But the name of each command loses that categorization. too bad. why not using something prefixes like: - gtp_admin for admin - gtp_setup for setup and so on... to give : - for admin : gtp_admin_list_commands, gtp_admin_version, gtp_admin_protocol_version, etc. - for setup : gtp_setup_boardsize, gtp_setup_place_stone, gtp_setup_komi, etc. - for core play : gtp_play_play, gtp_play_genmove, etc. - etc.
Perhaps each command should have a verb indicating what is the action : gtp_admin_get_version instead of gtp_admin_version gtp_setup_set_komi instead of gtp_setup_komi gtp_play_do_play instead of gtp_play_play (play play please i'm waiting for your move, computer)
the benefits : commands following a norm, are more intuitive, talkative to a human, at no cost.
3- Perhaps the spec should indicate how the sequence of command needed to setup a game through an example : - identify the protocol used by the program anygo> gtp_admin_get_version ?\n\n (here it's definitely v2) anygo> protocol_version 2 - set the board size : anygo> boardsize 19 =\n\n etc.
or
anygo> gtp_admin_get_version = 3 1\n\n(oups did i really put two integers here?) anygo> gtp_admin_get_capabilities setup (query the program) = max_handicap_ro 9 accept_square_board_ro true accept_rectangular_board_ro false etc. (oh my you put all the keys and the values on the same line... it's in-mail optimization) anygo> gtp_setup_set_boardsize 19 23 (set board size) ?\n\n (oups) anygo> gtp_setup_set_boardsize 19 = 19x19\n\n (that's better) anygo> gtp_setup_set_handicap 5 = 5\n\n anygo> gtp_setup_set_komi 3.5 = 3.5\n\n anygo> gtp_setup_place_stones W C4 B D6 (setup initial stones if any) = 2\n\n anygo> gtp_play_do_genmove B = P13\n\n etc.
WELL CAN'T YOU JUST STOP ?
ok that's enough. That was my contribution to the subject. Odds are it will go directly to the paper basket... still, i had to try .
and perhaps the matter will re-emerge out of my twisted mind the day i decide to spend some time to create my UI... (oh my, where's that d... diving suite of mine?)
Best regards. Rodrigue.
Hi Rodrigue,
Your view of what the protocol should be like includes a lot of things rarely used in practice. There is no limit to the ways you could expand the protocol, but one has to ask how practical is it versus how much does it make the protocol unduly burdensome.
My biggest complaint has to do with synchronous nature of the protocol and I personally see GTP limitations in a completely different way than you do. It never once occurred to me that not supporting 27x27 boards is a serious limitation.
Your suggestions are not unreasonable however. The boardsize command could take 2 arguments, width and heights, and the coordinates could take integer arguments in place of actual Go coordinates.
But I doubt many consider these things very important. In many ways it would be a loss to see moves described as 3,3 instead of C3. In fact this is one of the complaints against SGF format, it's not very human readable.
Time control is a hairy issue. I too would like to see this added but it must be thought out very carefully. I would like to see it be flexible enough to express many different time systems without being difficult to implement.
Your ideas could be implemented as an extension of GTP. Boardsize could accept an optional 2nd argument and the moves could also be accepted in one of two formats. I would probably suggest that the definition of a move be expanded to include hyphenated coordinates. So you could send or accept C3 or 3-3 as a move (and 3,3 should probably be ok as long as there were no spaces.)
In other words some of your suggestions could be incorporated in such a way that there is total backwards compatibility. An old fashioned controller could work with the new abridged protocol. If you send boardsize that way too, I think you could use a modern controller with an old-fashion GTP program - it would just return an error if it didn't understand. So you could send "boardsize 19", "boardsize 19x19", or "boardsize 12x7" and older program would simply balk at the older usage.
All of these things can be implemented with 100% compatibility if you simple define new GTP commands - GTP is not short-sighted about this. So define your own boardsize and play command. The only problem with extended commands is that they are not standard.
- Don
On Tue, 2007-08-21 at 21:12 +0200, Rodrigue ASSARD wrote:
Dear list,
first of all, my intention is by any means to hurt anyone's feeling nor to start any flame war.
This said, IMHO i think this spec is a little shortsighted ...
Here are at least three reasons why :
1- the BOARD command should accept to create rectangular gobans... the question is why restrict it to square only ? I understand gtp is designed to enable testing on software programs ? then please let the possibility to foster some diversity... It would be good to see gnugo on a 4x7 board for instance :-)
2- "Boards larger than 25x25 are not supported by the protocol." Why ? Is it so complex to use another coordinate systems as 1,1 instead of A1 ? I know SGF has the same limitations, but why imposing such limitations ? is that another heresy to think about a 51x53 board ? played by two softwares for instance ? OK i'm definitely an heretic... for now :-)
3- the last but not the least concerns the time_settings. And here it's a special request : why not offer the possibility to set different time settings for each player ? again i think it would be fun to afford more time for gnugo than for myself. That would put more pressure on me...
ok i talk a lot about gnugo but i understand that the spec is tightly bound to gnugo or the opposite ...
Hope that i'm not off topic.
Best regards. Rodrigue.
gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp