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

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



Hi Tim,

   Hmm... how about this scenario..

   There are two players, A and B.

   Both A and B have passed.
   All of A's groups are alive.
   All of B's groups are alive.
   A thinks all of it's own and B's groups are alive.
   B thinks all of it's own groups are alive, but that one of A's is not.
   A implements the protocol to play on... but doesn't need to play.
   B doesn't implement the protocol to play on, so doesn't play.

   I think this could result in the kind of problems we saw on Sunday.  
   Because B isn't playing to kill the stones he thinks are dead, somehow 
   the protocol gets in a loop, where both programs continually disagree, 
   but play does not continue.

   I think this is actually a worse scenario from a practical point of 
   view.  :)


The KGS cleanup isn't recursive.  It only happens once:

The protocol is that once both players pass consectively,  kgs-genmove_cleanup
is sent.   The game continues until we get 2 more passes.  There is no further
checking after this.   The score is final even if they disagree.  The server
doesn't even ask if they agree,  it just scores the game.

- Don



   X-Original-To: computer-go@xxxxxxxxxxxxxxxxx
   Date: Tue, 07 Jun 2005 22:43:31 +0200
   From: Tim Foden <tim@xxxxxxxxxxxxxxxxx>
   X-Accept-Language: en-us, en
   X-Antivirus-Scanner: Clean mail though you should still use an Antivirus.
	   Virus Scanner running on Apollo.burtonhosting.com. Please
	   contact the helpdesk if you experience any problems using this
	   service.
   X-AntiAbuse: This header was added to track abuse,
	   please include it with any abuse report
   X-AntiAbuse: Primary Hostname - apollo.burtonhosting.com
   X-AntiAbuse: Original Domain - computer-go.org
   X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
   X-AntiAbuse: Sender Address Domain - 7sun.com
   X-Source: 
   X-Source-Args: 
   X-Source-Dir: 
   Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
   Sender: computer-go-bounces@xxxxxxxxxxxxxxxxx
   X-Spam-Score: -2.6
   X-Spam-Flag: NO
   X-Scanned-By: MIMEDefang 2.42

   Don Dailey wrote:

   >What's the worst thing that could happen?  A program will think it's
   >winning but fail to defend it's claim and lose the game.   But it's
   >not like the program didn't have a choice.   During the actual game,
   >the program is expected to defend itself,  why is it suddenly ok
   >not to defend itself when there is disagreement?    
   >
   >
   >So here is what you could easily have:
   >
   >  1. William Shuberts kgs-genmove_cleanup protocol
   >  2. A programmers choice whether to implement the protocol or not.
   >  3. A programmers choice HOW to implement it if he does implement it.
   >  4. A server that can easily score all games without human intervention.
   >
   >Even if your program accepts the "kgs-genmove_cleanup" it is up to the
   >program what it will do with the information (the knowledge that there
   >is a disagreement) and this can't be enforced by the rules of GO so it
   >can't properly be a requirement.
   >
   >But a good program will want accept this optional command and clear off
   >the opponents dead groups when it realizes the opponent is unaware that
   >his group is dead, otherwise it risks losing some points.   
   >  
   >
   Hmm... how about this scenario..

   There are two players, A and B.

   Both A and B have passed.
   All of A's groups are alive.
   All of B's groups are alive.
   A thinks all of it's own and B's groups are alive.
   B thinks all of it's own groups are alive, but that one of A's is not.
   A implements the protocol to play on... but doesn't need to play.
   B doesn't implement the protocol to play on, so doesn't play.

   I think this could result in the kind of problems we saw on Sunday.  
   Because B isn't playing to kill the stones he thinks are dead, somehow 
   the protocol gets in a loop, where both programs continually disagree, 
   but play does not continue.

   I think this is actually a worse scenario from a practical point of 
   view.  :)

   ~~~

   How can we fix this problem?

   Maybe this would do it -->  In the scoring phase, we actually have more 
   information than we have whilst playing... we know if the other player 
   thinks differently about the status of a group.  So in the scoring 
   phase, if there is a disagreement, the players should play it out until 
   they agree.  Agreed?  So from the above example, I would say that the 
   player B, that thinks a group is dead in disagreement to A, should move 
   to try to prove his case.  A is allowed to pass, as he doesn't need to 
   prove that a group is dead. If B actually passes, A's scoring should be 
   used for the game. 
   e.g.
   A. PASS.
   B. PASS.
   * Score disagreement. A thinks alive, B thinks dead.
   A. PASS.
   B. Must make a move, or abide by A's scoring.

   I think this would fix the problem for one prog that doesn't respond 
   correctly.

   ~~~

   If both programs act like B, then maybe we could say the rule is this.

   If there is a dispute, then the prog that thinks stones are dead _must 
   make a move_ or the game will be scored using the scoring of the other 
   player.

   e.g.
   A PASS
   B PASS
   * Score disagreement, A thinks some of B's stones actually dead, B 
   thinks some of A's actually dead.
   A. Must make a move, or abide by B's scoring.
   B. If A moved, {B can PASS}, else {B must make move, or abide by A's 
   scoring.}
   * play continues until 2 consecutive PASSes.
   If moves have been made, we {rescore, and repeat disagreement protocol 
   if necessary}, else {end of game.}

   Thus we guarantee to end a game, in any case.

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


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