On Fri, 2002-08-02 at 03:00, gunnar(a)lysator.liu.se wrote:
Bill wrote:
> 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?
It may look simpler but in reality it just exchanges extra commands
for higher complexity in other commands. With this construction one
would need to have a state keeping track of the number of remaining
handicap stones and also specify how to handle, alternatively
explicitly forbid, surprising things like mixing play and genmove
commands while doing handicap or undoing a couple of handicap stones.
> That seems simpler to implement and more flexible,
I don't agree. Both when I consider implementation for engines (in
particular GNU Go) and controllers, I prefer to handle the whole set
of handicap stones as a unit.
> 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.
I don't see where this additional flexibility comes in, except maybe
that the controller would be able to place white stones and call them
handicap stones. Please give an interesting scenario which my proposal
doesn't handle.
For flexibility, specifying exactly where handicaps stones go means you
can do handcaps not predicted in advance. For example, if you want to do
h-5 on a 12x12 board, you don't need to specify as part of the protocol
where exactly the 5th stone goes. This means that any handicap setup
that an arbiter program wants to use can be done, no need to have the
knowledge of this setup in the GTP programs. You can try fixed H-27 on a
19x19 and again, the program authors don't need to program in where all
27 stones go; you just make an arbiter than puts the 27 stones where you
think they go, and then *any* GTP program will work fine - they just put
the stones where they are told.
Another form of flexibility is working with other software. Different
internet servers put handicap stones in different places. Specifying
exactly where stones go in the protocol means you just can't play
handicap games on all servers - even if you get it working on one
server, on another you won't be compatible.
A last issue, not in flexibility but in removing potential (and probably
likely) errors is the need for all GTP implementations to agree on where
handicap stones go. The SGF protocol originally did this, and it turned
into a nightmare because it was so hard to keep all programs in
agreement. Yes, SGF specified that H-3 are placed at positions in
corners "a", "b", and "c", leaving "d" blank, but it was so easy for
programmers to accidentally leave "c" blank instead of "d", and it was
so hard to detect until incompatible SGF files started floating around.
SGF files now have "H-3, add black stones at these three locations",
which is much easier
> 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.
I can say with certainty that Canadian byo yomi is used in all Swedish
tournaments. From google searches I get the impression that it is also
the dominating time system in the rest of Europe and North and South
America. Maybe someone else can comment on that. It is also used at
the World Amateur Go Championship.
Ah, I have never played go in Sweden. But I can assure you, in the USA
at least, Canadian is rare. I have played at many tournaments both in
the Northwest corner of the USA and at the annual Congress, and have
never even heard of a canadian byo-yomi game in a tournament. All have
been either Japanese byo-yomi or fixed time.
> 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.
If needed this can be solved anyway, in the worst case by deprecating
"time_settings" and introducing one or more new commands. But one
should think twice before adding more time systems. As an engine
writer I'm not thrilled by the prospects of implementing and
maintaining multiple clock systems. Maybe this is easier if the engine
is designed to handle time issues from the beginning, but for GNU Go
time management is quite complex.
So you would rather plan on deprecating a command than make the command
extendible? Seems like a foolish decision to me. The nice thing about
adding the "canadian" word now is that you don't have to maintain
multiple time systems if you don't want to. If you only understand
canadian time, and see "time_settings japanese 120 30 5", you just
return an error, because you don't understand Japanese. If all GTP
tournaments stay with absolute time controls (or canadian), then fine,
people who only want to be in tournaments can write code that
understands only "canadian" and "absolute". But if you want your client
to be able to play against people using other time controls, it would be
nice for the protocol to be able to cleanly allow client writers to do
so. Deprecating a command and replacing it is *not* clean.
PS - I apologize for my last post being in mixed HTML and text. It's so
embarassing to forget to switch for a mailing list, makes the digest so
ugly. :-(
