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

[computer-go] Protocol B



From: John Tromp <John.Tromp@xxxxxxxxxxxxxxxxx>
Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
Subject: Re: [computer-go] KGS game-end protocol
Date: Wed, 27 Jul 2005 15:14:28 +0200




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?



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?



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.

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.



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.





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?



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?



cheers,

Peter






regards,
-John


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



_________________________________________________________________
Need a new job? Check out XtraMSN Careers http://xtramsn.co.nz/careers

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