[computer-go] Fw: Compensation for handicap plays?

[Nick Apperson]

using gen_move to place handicap stones seems unreasonable to me when there
is a command intended for that purpose.  The point of GTP is to make it easy
to implement the protocol.  Anything that either breaks programs that are
written to the specification (as in using gen_move instead of
free_place_handicap) or makes GTP more complicated works.  "Implicit"
handicaps are rediculous.  Send it as the komi.  The following steps will
always make it clear to any bot that implements GTP correctly what they
should do:

1) send a komi
2) use the handicap functions built into GTP if they are supported
3) else, use gen_move
4) send play_move to other client
5) play out the game until both players pass
6) ask engines what stones are dead
7) if they disagree, keep playing if they support that
8) when both players pass again, ask them both to score the game
9) programs can score however they want, but it should be consistent with
the following:
    black wins if (# of black stones on board + # of spaces black has as
territory) > (komi + # of white stones on board + # of spaces white has as
territory)

chinese rules are consistent with this approach as are japanese rules if
both players pass an equal number of times.  Further, the komi should
include all compensation given because then programs don't need to be
programmed to support various different sets of compensation.  kgsGTP should
either have a layer put on top or itself altered so that komi includes all
compensation.  This was a mistake imho in how GTP talks with KGS and it
should be fixed.  These are just my thoughts.

- Nick

On 12/29/06, Weston Markham <weston.markham at gmail.com> wrote:
>
> As someone who might write programs that will play on the server, I
> would like to put my 2 cents in:
>
> As long as the final score is simply the difference in the number of
> intersections controlled by each of the players, adjusted by komi,
> then I will be happy.  Whatever compensation for the handicap stones
> is decided upon, it should be accounted for in the komi value sent by
> the server, which should be exactly the komi value that is used to
> adjust the final Tromp-Taylor score.  (This is clearly what Dave
> Hillis has in mind.  Am I correct in inferring that this is also what
> Don Dailey has in mind, but with no compensation for the handicap
> stones?)
>
> If I understand correctly, kgsGtp relies on some mechanism where the
> compensation is implicit; so, either the komi value is not specified
> by the server, or the komi value that is used to adjust the final
> score is not the same as the value that is sent by the server.  (I am
> not aware which is the case, since I have never used kgsGtp.)  This
> might be incompatible with the mechanism that I describe above.  If
> that is the case, it would be nice to have both of the GTP controller
> programs would have special commands (say, "kgs_rules" and/or
> "cgos_rules") that would be sent to the programs, in order to
> explicitly inform them of the rules that are in effect.  (These could
> take version numbers of the rule sets, as arguments, in order to allow
> for future changes to the rules.)
>
> Aside from this, I have one very minor complaint about simply asking
> one player for multiple consecutive moves.  In my opinion, the player
> should know ahead of time how many consecutive moves will be
> requested.  The proposed method should only be used as a fallback, if
> there are programs that we would like to participate on CGOS, but for
> some reason these cannot be easily made to provide a
> place_free_handicap command.  Even in that event, I would personally
> prefer to simply wrap those programs behind adapter programs that will
> automatically perform the translation of place_free_handicap to
> multiple genmove commands.  (Does gtpadapter, available in gogui,
> already do it?)
>
> This latter point is minor.  If I don't get what I want, it really
> won't bother me much.  However, at the moment it seems to me that it
> should be such a small burden on developers to support the command,
> that it is worthwhile to ask.
>
> Weston
>
> On 12/29/06, dhillismail at netscape.net <dhillismail at netscape.net> wrote:
> >
> >       This seems clean and reasonable to me. (Or you could just as
> easily
> > have the server do the adjustment and set Komi to 3.5; that would also
> be
> > consistent with TT rules). If my bot sees 2 black moves in a row, it can
> > figure out it's in a handicap game.
> >       A bigger question to me is, how large a handicap might be
> encountered.
> > Will we see Mogo playing Random with 100 stone handicap, or will
> excessive
> > mismatches be disallowed altogether?
> >
> > Dave Hillis
> >
> >  -----Original Message-----
> >  From: drd at mit.edu
> > On Fri, 2006-
> > ....
> > If your program is taking black you would get someting
> > like this from the GTP channel:
> >
> >  clear_board
> >  komi 0.5
> >  boardsize 19
> >  genmove black
> >  genmove black
> >  genmove black
> >
> > for a 3 stone handicap game. The opponent would get the
> > corresponding consecutive play commands.
> >
> > I know this won't make everyone happy - but I believe it is
> > more in the spirit of a simple logical rule-set and is what
> > drew me to Tromp/Taylor rules in the first place. Might as
> > well stick close to it.
> >
> > We can call this rule-set "CGOS" - which is exactly tromp/taylor
> > without suicide.
> >
> > - Don
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > computer-go mailing list
> > computer-go at computer-go.org
> > http://www.computer-go.org/mailman/listinfo/computer-go/
> >
> >
> >  ________________________________
> >  Check Out the new free AIM(R) Mail -- 2 GB of storage and
> industry-leading
> > spam and email virus protection.
> >
> > _______________________________________________
> > computer-go mailing list
> > computer-go at computer-go.org
> > http://www.computer-go.org/mailman/listinfo/computer-go/
> >
> >
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://computer-go.org/pipermail/computer-go/attachments/20061229/04bbf5b9/attachment.htm