Re: computer-go: Engineering (was: Most simple Go rules)

[William Harold Newman <william.newman@xxxxxxxxxxx>]

On Sat, Jun 30, 2001 at 10:40:47AM -0400, Christian Nentwich wrote:
> 
> >     At the end of a game between humans, there is a "negotiation phase".
> > Each player makes assertions about the status of groups, and there is a
> > procedure for resolving any disagreements.  This is not just a
> > theoretical construct, this is what really happens at the end of a game
> > between two human 9-kyus.
> >     Computers cannot do this negotiation.  Therefore, the only way a
> > computer has for demonstrating that an enemy group is dead, is to
> > capture it.  Under J rules, it cannot do this without incurring a
> > penalty.  Under C rules, there is no penalty for demonstrating, after
> > the last constructive move but before the game end, that an enemy group
> 
> What 9 kyus normally do  is something like this though (?):
> 
> White: that group is dead
> Black: no it's not
> White: try me
> Black: <moves>
> White: <moves>
> Black: ok, it's dead
> 
> This is probably against the rules after passing twice, but happens in
> clubs everywhere. There is no penalty for white here, since its black
> who's trying to live and plays a stone first, white answers.
> 
> You don't show that a group is dead, your opponent has to show that it
> can live, otherwise it's dead. No penalty for White, since he doesn't
> have to show how to capture in the first
> place unless black plays. I see no problem implementing that in a formal
                                  ^^^^^^^^^^
> protocol .

There are at least three relevant meanings of "a problem" here.

"I see no problem, it's clearly straightforward to implement this." I
think everyone agrees that it's straightforward to implement this.

"I see no problem, it's aesthetic to implement this." I don't wholly
agree. In a normal group I might be in a small minority, but I might
not be here. People who place a strong aesthetic priority on
simplicity are overrepresented among programmers and Go enthusiasts.

"I see no problem, it's not undesirable feature creep." (Or "Feature
creep? What's that?":-) People at the IETF, who know a thing or two
about coming to agreement on workable protocols, often quote somebody
(who I couldn't find credited in a few minutes of Googling) as saying
(short form) "rough consensus and running code" or (long form) "We
don't believe in kings, presidents, or voting. We believe in rough
consensus and running code." I suspect that if people were actually
producing prototypes which incorporated their proposed features, it'd
be pretty obvious that adding a negotiation phase significantly
increases the complexity, at least relative to the extreme simplicity
of Chinese scoring of games played out to the bitter end.

-- 
William Harold Newman <william.newman@xxxxxxxxxxxxxxxxx>
As usual, this being a 1.3.x release, I haven't even compiled this
kernel yet.  So if it works, you should be doubly impressed. 
  -- Linus Torvalds, announcing kernel 1.3.3 on the linux-kernel mailing list.
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C