[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [computer-go] Protocol B

On 27, Jul 2005, at 7:32 PM, drd@xxxxxxxxxxxxxxxxx wrote:
I also have given this further thought. I'm now slightly in favor of
actually coming to an agreement on which stones are dead using the same basic
protocol you are specifying here.

The reason? Just an extra nicety for marking the board at the end of the
game. Although the winner/loser result is by far the most important, it
is probably very useful "for the record" to understand exactly how the game
was scored, perhaps for games database research. When a game has been
finished, it's a special convenience for any observer to see how the board
was actually marked and it takes the pressure off of automated software to do
this. As an example, how would Nicks program mark the final position if
there was no reporting of dead stones?

Also, it would make life easier for reporting game results in general,
because people usually care about the actual area score and it's usually
recorded in databases.
The scores returned by the programs can still be put into the database,
one, the other, or both ... whatever seems best to the database. That
detail is less important to me. If someone feels strongly maybe their
reasons are more important.

It's not a big deal to me, it's more important to have a protocol but I can't
help feel that if we adopted this protocol, we might regret not having the
stone information.

I agree that all of these extra conveniences would come with the
automated marking of the board, but I would not really like to see
the agreement/disagreement loop having to be repeated if both
programs agree on the winner but have minor disagreements on
the status of particular stones. My primary thought is that this more
specific information is likely the concern of the programmers
rather than anyone else. As had been mentioned, there is some
desire to keep the barrier to entry in tournaments relatively low,
so the newer programs could have weaker endgame analysis
and still participate with out causing repeated loops through the
resolution phase.

In any event, I'd like to start with the simplest protocol that does
what we need most. The protocol should not preclude the features
that we would like to add later, and then after the simple protocol
is well established the other features can be added.

What we are calling Protocol B will let two programs get to the end
of a game agreeing which is the winner. I don't see any reason
why it would preclude a richer or more specific set of agreements,
but I think it would be simpler if after this end-of-game agreement
is reached each program independently passed their "marked"
board to the server. If they match, great. If they do not then the
server could just store both. Those who care can inspect them
to extract whatever information they are seeking. An alternative
might be to have a known solid code do the after game markup,
although it may be interesting if the programs playing the game
agree but the marking code gets a different result.

Does that fit well enough with the way KGS does things ... or at
least meet our primary needs for the moment?
I'm not sure it is absolutely necessary to have the special
resolve-disagreement-genmove command, since a program can infer this from the
fact of multiple passes. But I can see why some might feel it is better to
be explicit. It seems slightly cleaner and simpler not to have the extra
command but it's nothing I would lose any sleep over either way.
The main reason I though it best to be explicit is that some engines
do not store state information like the exact sequence of previous
moves, only the board state. They could be modified to store previous
pass information, but it may be otherwise unnatural for their code. An
explicit command makes it perfectly clear without assuming stored state.
I was also influenced by the original proposal of KGS-cleanup-genmove.
The specific name is not of much consequence, but (adjective)-genmove
seems most natural to me.

It seems that at least Don and I are growing comfortable with this ... what
do other people out there think?


Cheers,
David


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