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

Re: [computer-go] Protocol B

On 27, Jul 2005, at 10:04 AM, Peter McKenzie wrote:


From: John Tromp <John.Tromp@xxxxxxxxxxxxxxxxx>

On Wednesday 27 July 2005 3:33 am, Gunnar Farnebäck wrote:

...  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.
Isn't an automated tournament where the players themselves determine
the final score preferable to one where an imperfect 3rd party is called
upon to resolve disputes?
My only problem with Gunnar's idea is that when one of the programs in
the tournament game is GNU Go, this has a bias. I think we are trying to
avoid saying that one of the programs in the tournament is apriori correct
(even if this is true).

If two programs disagree on the outcome, then they should be given a chance
to resolve their disagreement.

For a protocol, there's the question of what it is that the players should
agree on. Is it just the score, or the status of each string?
I would favor score first, and then going down to strings only if there is no
simple way to end the dispute. Previously I had asked for lists of stones
involved in the dispute, but I now think that is a complication that should
be avoided if easily possible.

In any case, suppose both players are informed of the relevant details
of the disagreement, then play can proceed.

Now, only if both players pass immediately in the resumption,
is it necessary to force a result.
Yes, if both programs insist upon passing again after they are told there
is a dispute, something must be done. My preference, considering the
state of computer Go and the range of strengths we see in the tournaments,
has been to have the tournament director and the two programmers consult,
just as Nick has done. I believe that humans will sensible reach the correct
solution.

But we are searching for an automated protocol ...

The most sensible thing to do then is, in my opinion,
to simply rule every string on the board as alive.
Compared to a 3rd party ruling, this has the advantage that both
players can be fully aware of the outcome,
and thus have no reason to complain about it. If either player is not happy
with this outcome, then they need only make a move in the resumption.
Preferably, this move should help to resolve the disagreement, but there's
no way to enforce such a thing.

If either side makes a move in the resumption, then it is as if the original
two consecutive passes never happened, and the programs can be given another
chance to agree at the next two consecutive passes.
This suggestion changes things considerably and is far more acceptable
to me. Under this protocol my complaint is only valid for one move, as long
as the tournament is played under Chinese scoring rules.

I see no reason to limit the number of resumptions to only 1. It makes
the protocol more state-full, and leaves the players no discretion to
just resolve disagreement on one string while remaining in agreement
about other dead stones on the board.
I much prefer that this proposal carries this state information for only one
move. This is an important distinction to me.

John, this is the more sophistocated protocol which I made reference to some (many) posts ago. I wonder if David Doshay (and others) would be happier with this protocol?
Indeed I do. I find it less that perfect, but perhaps the best we can do now.

Actually, your description needs fleshing out a little. For purposes of discussion, I call the more sophistocated protocol 'protocol B' and the simpler protocol being discussed 'protocol A'.

A key thing that a program needs to know is: 'If I pass now, is there a chance that all stones will be declared alive?'. Under protocol A a program knows this because it has been passed a 'KGS-genmove_cleanup' command (instead of a normal 'genmove' command).

Would protocol B also use the 'KGS-genmove_cleanup' command? Perhaps 'KGS-genmove_cleanup' would be sent to the program to move following a score disagreement. If that program makes a non-pass move then a 'genmove' would be sent to the other program and the game continues 'as normal'. But if the first program passed, then a 'KGS-genmove_cleanup' would also be sent to the second program. If the second program also passes, then the game is scored with all stones assumed to be alive. If the second program makes a non-pass move then we are back into 'normal' gameplay.

Sound reasonable?
At this time I think that this may be the best combination of reasonable
and simple we can quickly agree to.

I have been thinking since yesterday about a protocol based upon
"show me the eyes" rather than "show me who is dead." I was unable
to get very far because the communication protocol would require
the transfer of lists of stones in strings and their eyes. I was concerned
that some programs, perhaps neural nets or some other method that I
had not thought of, would not be oriented towards the more normal
stone, string, group ... analysis, and those programs should not be
made to jump through hoops to process information into forms that are
not natural to their programs. I guess we all know about single locations
on the board, so it could all build up from there. But I am mumbling ...

My point is that a protocol that requires transferring lists of stones,
groups, eyes or whatever, is far more complicated than:

(pass - pass)
?score?
if agree
no problem, game over
if disagree
resolve-disagreement-genmove
if reply is pass
resolve-disagreement-genmove
if reply is pass
game over, everyone alive
if reply is not pass
continue game with genmove
if reply is not pass
continue game with genmove

In this protocol neither side needs to be told anything about the other
program's view of the game and neither program has to present lists
of stones (alive or dead) or eyes to the server, either for interpretation
or retransmission to the other program. I do not think it unreasonable
that each program be asked to calculate the score at the end of the
game. And the state I have complained about only exists for one move
and is implicit in the server's request for the move. While there is still a
slight asymmetry in who is asked first, I accept the argument that if you
pass at this stage you know what it means. Because the state is not
persistent I am no longer opposed to this protocol.

It works well enough for me and looks to be easy to implement on the
server and in any Go playing program.

What do others think?

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