Re: computer-go: Most simple Go rules

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

David,

Any thing that   is possible can be  done  and justified, but what  is
being explored  is  a simplification and a  suggested standardization.
You make a point by point defense of keeping and using several scoring
formats that you have already implemented, but the discussion is about
using a  single logical scoring system.  You  didn't make  a case that
all these other system  are very logical, only that  they all had some
kind of workaround or justification.

More comments below ...


   Date: Tue, 26 Jun 2001 00:14:57 -0700
   From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>

   At 11:29 AM 6/25/2001 -0400, you wrote:

   >I agree, that maintaining the illusion that computers play grown-up Go,
   >is only causing problems. Humans can use an agreement phase because of
   >their comprehensive communication protocols.
   >Since computers lack these, avoiding an agreement phase seems essential
   >to well defined outcomes in CG tournaments.

   Computers can have an agreement phase as well.  Many tournaments required that
   programs be able to show which groups they think are dead at the end of the 
   game.

Of course they can  have an agreement  phase.  The whole point is that
this is cumbersome and messy and involves a lot more protocol.

You  are  ignoring the main  point   of simplification, and pretending
there are no  advantages to doing  it a different way.  With something
like Tromp/Taylor  (which is  NOT a  great burden  to implement by the
way) the  protocol  is 2 passes  and  both  computers report  the same
score.   The computers will   not disagree unless  the programmers are
brain dead.


   >Nick also said implementing superko is difficult. On the contrary, it is
   >next to trivial, especially when compared with all the other things that
   >need to go into a go program. (maintain a table of 64bit hashes of previous
   >positions).
   >You don't want to deal with the headache of 2 programs playing infinitely
   >in a triple ko. If a programmer thinks triple kos are too rare to bother
   >with, then (s)he is free not to implement superko and risk a loss.

   How many different rule-sets do you think the programmers should 
   implement?  

For tournaments they  should implement a  single  agreed upon ruleset.
But for commercial use programmers  should implement every ruleset  in
common use and provide toggling of elements of these sets.


   I'd rather
   make the program stronger than implement another rule-set.  Most people 
   just implement
   one.  If it is Japanese, it won't allow suicide.  I've had to implement 
   Chinese, Ing, Japanese, AGA
   already.  Now you want me to add superko, and tromp-taylor?  It seems a 
   little much.

Programmers can implement whatever set(s) they  want, but if they want
to compete  they should have to  only  implement one  logical rule set
which is what  we are talking  about here.   

We are not talking  about what they do  now, we are talking about what
would  be most logical.  It  may never come  to pass that we do things
logically, but I would guess most programmers would want this.


   >I think forfeiting programs that don't accept a suicide may also be a good
   >idea, since it fosters an mentality of making go programs more robust and
   >able to cope easily with slight rule changes.

   Accepting suicide doesn't make a Japanese program more robust.  It makes it 
   less robust since
   it will accept an illegal move.  Any programmer that hopes to sell his 
   program will implement
   Japanese rules first, since that's what most people play in the west, and 
   Japan is where you
   can sell your software.  For this programmer, accepting suicide would be a 
   bad idea.


I agree with you here.   It seems pretty silly to  call this a feature
or improvement (try doing this to a chess program and you will get bug
reports.)  I would still  provide a switch  to accept these moves just
in case a competing program wants to give me stones.

The fact    remains that something   like  Tromp/Taylor  is absolutely
trivial to implement, eliminates  a great deal of man/machine protocol
and would make it much easier for beginning Go programmers to get this
part of  the game right.  This  last  point is  important, it's not in
your (our) best interest to discourage them in  any way.  I'm speaking
partly for myself here because I am a beginner.

Don


   David


   >regards,
   >
   >%!PS                       %  -John Tromp (http://www.cwi.nl/~tromp/)
   >42 42 scale 7 9 translate .07 setlinewidth .5 setgray/c{arc clip fill
   >setgray}def 1 0 0 42 1 0 c 0 1 1{0 3 3 90 270 arc 0 0 6 0 -3 3 90 270
   >arcn 270 90 c -2 2 4{-6 moveto 0 12 rlineto}for -5 2 5{-3 exch moveto
   >9 0 rlineto}for stroke 0 0 3 1 1 0 c 180 rotate initclip}for showpage

   David Fotland