Re: computer-go: Go Text Protocol (GTP)

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

Hi William,

There is   no negotiation protocol in   what  I am  suggesting  but my
description   kind of made   it  sound like  that.   The client either
understands a  command or it doesn't.   If a command  is sent that the
client doesn't understand, the only requirement  is that it sends back
a "not_implemented" response.

As you are suggesting, there should also be  a mode that the interface
understands to be, "play without arbitration."  In this mode, the user
interface will  not try to set  up a ruleset and  will not judge moves
for legality.  It will  do  nothing but relay   moves back  and  forth
between client(s).  It will accept all KO moves, all suicide moves and
will consider the game never over.

I  think my description  of things made  it  sound overly complicated.

Don





   Date: Tue, 31 Jul 2001 12:00:19 -0500
   From: William Harold Newman <william.newman@xxxxxxxxxxxxxxxxx>
   Sender: owner-computer-go@xxxxxxxxxxxxxxxxx

   On Tue, Jul 31, 2001 at 11:27:25AM -0400, Don Dailey wrote:
   > One complexity with a minimal set has to do with which rules are being
   > honored.  I don't  care about "prisoners" if I  am  not using Japanese
   > rules for  instance (even though I  could implement it anyway, in this
   > particular case it would be meaningless.)
   > 
   > How to handle  this?  There are 2 major  ruleset branches (Chinese and
   > Japanese) each  having various  minor  variations in the play  of  the
   > game.  The  minimal GTP  command set  should be complete  enough to be
   > capable of determining if  2 separate programs  are able to honor  the
   > same set of rules.  So I suggest that it's ok to say "not_implemented"
   > to any   question of  rules, as long   as ANY  program  that claims to
   > implement the minimal GTP set can default to Tromp/Taylor rules.  This
   > has 2 major side benefits:
   > 
   >    1. Any 2 programs can play a match with the same rules.
   > 
   >    2. The minimal GTP command set is easy to implement.

   I mostly agree, but IMHO it's also important to support trivial
   conforming programs in two other cases, and it's not clear that this
   proposal would make those trivial. (I don't think think this is a
   severe criticism of the proposal: I think the proposal might make my
   Case I below hard, but I don't think it's hard to modify the proposal
   to change that.)

   Case I is a minimal client playing non-TT rules where the rules are
   known by an outside channel, e.g. e-mail from the tournament
   organizer. (Also, similarly, other things like time control, handicap,
   board size, or what color the program is playing may be known by an
   outside channel.) In that case, there should be some way for a
   conforming program to decline to negotiate (probably because it was
   written to be dead simple and doesn't know how to negotiate:-) without
   implicitly saying it's playing TT rules, 19x19 board, etc.

   So I think any negotiation protocol should support not only your
   trivial response "negotiation not implemented, i.e. use TT", but
   another trivial response, "negotiation not implemented, i.e. use the
   local default, which you should know by some outside channel."

   Case II is a minimal server, or a server written without support for a
   particular ruleset variant; in any case, a server being used to
   arbitrate a contest with rules and/or time controls that it doesn't
   fully understand. It should be possible for a conforming server to
   operate "non-judgmentally", simply recording the moves and their times
   (without testing their legality or whether the time limit was
   exceeded), and telling the clients how much time they've used so far
   (without trying to calculate how much time they have left). Thus, it's
   possible to leave any check for rule violation to some smarter entity
   which examines the game record later.

   -- 
   William Harold Newman <william.newman@xxxxxxxxxxxxxxxxx>
   Communication would be much more reliable if people would turn off the
   gainy decompression. -- Del Cotter
   PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C