[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: computer-go: gnu-go agreement protocol



   From: Gunnar Farnebäck <gunnar@xxxxxxxxxxxxxxxxx>

   Don Dailey wrote:
   > What are   the  chances that  the   agreement protocol we    have been
   > discussing on this  group  get implemented in  gnugo  as part of   the
   > Tromp/Taylor ruleset that you say will soon get implemented?

   Ruleset may be a bit of an overinterpretation. In the next version
   there will be an option which forces GNU Go to play on until all dead
   opponent stones are removed, but it won't stop to pass once just
   because it thinks everything is settled and dame filled. There also is
   no implementation of area scoring currently so it won't be of much
   help stating the score. These things will certainly be implemented
   sooner or later, all the hard stuff is already there. But in the next
   version it will only be useful for Tromp/Taylor without any early
   agreement and scoring done by the arbiter (or the opponent).

I am happy that you will be  implementing Tromp/Taylor at all.  I will
probably  forget about the early agreement  stuff, as  it is likely to
stifle peoples desire to implement Tromp/Taylor in general.

Don


   > Before I go  to  the trouble, it  would   be nice  to think  that  the
   > protocol is somehting that at least one other program will understand.
   > More importantly,  since this is  an optional protocol my main concern
   > is simply that it gets documented and there is some standardizatoin of
   > the format of a  new GTP  command to support   it (I believe  the only
   > thing needed is a  GTP command to give a  score  to the arbiter  while
   > making a pass move.)

   I don't think it's necessary to have a special genmove command with
   this property. When the arbiter gets two successive passes it could
   simply issue final_score commands to both programs to ask their
   opinion.

   John Tromp wrote:
   > Does 1) suffice or are there cases where the extra information in 2)
   > is useful?  A further alternative is to include the komi in the
   > above, but I think it's cleaner to focus on the board score. The
   > arbiter will then take komi into account to decide the winner.

   To me it seems natural to include the komi. After all the programs
   need to be informed of the komi beforehand anyway, for strategical
   reasons. (That some programs, like GNU Go 2.6, doesn't care about the
   score when generating moves is beside the point.)

   /Gunnar