Re: computer-go: Most simple Go rules

[John Tromp <tromp@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

> >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.

It's easy to fulfill such a requirement; claim all opponent groups to be dead,
or all the ones u cannot recognize as having 2 solid eyes. Do you propose
a penalty for incorrect claims?

> >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?  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.

No, I don't want you to implement a dozen rulesets. I want programs to be
able to adapt to the major choices:

-counting chinese or japanese style
-allowing or forbidding suicide

and to a lesser extent the minor choices:

-situational or positional superko
-whether to score points in seki
-how many passes end a game

> >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 

I'm not saying programs should be rigid. They should be able to cope with
both choices. That's what I mean by robust.

-john