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

[steve uurtamo <apoxonpoo@xxxxxxxxx>]

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

my examples involving dame and a simple ko fight
were meant to illustrate how humans at different
levels of play can misunderstand the status of
various groups on the board.  computers are
nowhere near being able to correctly evaluate at
the level (and with the speed) that humans can,
so the kinds of errors that they're likely to
have with respect to endgame status will be much
more "obvious looking" to us.

one objection that i don't understand to playing
out the endgame until it's evaluable by simple
observation (or by an algorithm that is easy to
understand and can give an unambiguous yes/no for
each stone on the board in a short period of time)
is that it "wouldn't be interesting for humans
to watch".  my thinking is that at this stage,
that should be the least of our concerns.  there
should be some degree of provability with respect
to life/death of stones on the board.  and this
provability shouldn't require human intervention.

the fact that both players passed before disagreeing
about stone status is almost incidental to the fact
that they don't agree.  clearly, if they don't agree,
either one of the two pieces of code is missing an
important line of play, or neither of the two pieces
of code understand the actual status of some of the
stones on the board.  in either case, it's worth
finding out who is right and who is wrong.  and if
both pieces of code can generate beautiful looking
endgame situations, but neither of them knows how
to kill mostly-dead stones, then this protocol would
definitely point out weaknesses in those programs. 

leaving it up to a human to evaluate endgame
situations gives an unseen advantage to the
computer go programs out there -- all they have
to do is generate board situations that are
advantageous, without necessarily being able to
kill stones that are mostly-dead.  it actually
handicaps computer go program development if they
can take advantage of the magic black box of a
human evaluation function to finish games for
them.

keep in mind that what humans call dead changes
as their skill level increases.  in the beginning,
it's just single stones trapped behind enemy lines.
however, who hasn't seen a single stone in such
a situation spring to life at the hands of a much
more skilled player?  it might legitimately be dead
if both players were of equivalent skill, but 
potentially alive otherwise.

i think that it's important for go programs to
be able to prove, by playing moves, that the stones
that they think are dead cannot be defended.  sure,
it's boring to watch, and a board full of 1-point
eyes isn't going to be as pretty looking as one
with vast chunks of open space, but it shouldn't
take more than a fraction of a second or so for
each such move (and if it *does* take longer than
that, then the code in question certainly hasn't
already read out that line of play and can't say
for certain that the "dead stone" is really dead).

i think that the idea of a gnugo evaluation function
is along the right lines, but it needs to be a little
bit less black box.

s.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/