Re: [computer-go] KGS game-end protocol

[Gunnar Farnebäck <gunnar@xxxxxxxxxxxxxx>]

Steve wrote:
> > Really, GNU Go
> > and probably some
> > more programs are good enough at scoring to do this.
> 
> only until there's code out there that is
> significantly better than gnugo.
> 
> i was thinking about this earlier.  imagine that
> you're playing someone much, much better than you
> are.  they may look at a ko fight toward the end
> of the game and think, "of course, this is
> unnecessary, since you have far fewer ko threats."
> however, they will be *forced* to respond to your
> ko threats because by not responding, they will
> be losing valuable influence and likely territory.
> 
> so even though one of the two players knows the
> outcome of the fight, they are legitimately forced
> to respond to threats that require a response.
> 
> dame may seem silly to humans, but failing to respond
> to one of the last liberties your group has could
> mean loss of the entire game.  trivial for 
> non-beginners, but something that really implies a
> deeper understanding of the game.
> 
> how many of us have lost games that were won by
> failing to respond to a dame point?  how many times
> did that happen?  once, twice?  how many times would
> your code fail to correctly respond?
> 
> i think that being able to deal with endgame play
> is a pretty reasonable request.  over isn't over
> until there aren't any more points that could gain
> territory.  usually the game ends well before then,
> and a piece of code which can correctly determine
> this should be more likely to resign than to fail
> to play it out.

What are you talking about? Nobody has suggested to stop the play
before both programs agree that the game is over. If one program
passes while there are still points to gain it's their loss. If both
programs pass prematurely it's still their problem.

The whole discussion is about what to do when the programs agree that
the game is over but they do not agree about the status of some stones
on the board. Some people suggest requiring the programs to play it
out until they have captured all stones they think are dead. My
suggestion is that the status is determined by a separate scoring
engine and I claim that e.g. GNU Go is good enough at determining
status at the end of game for this to be practical. If you disagree
with this, please give some concrete examples where it fails.

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/