[computer-go] Protocol - C

[drd@xxxxxxx]

On Thursday 28 July 2005 9:36 am, Eric Boesch wrote:
> It's annoying and it's bad manners to offer a draw in chess after every
> move, even if you're right and the game is theoretically drawn.  Similarly,
> if you get into a dispute under Chinese rules, you don't play one move and
> then pass and go through the whole process again.  If the players don't
> agree during the first agreement phase, then it's too late to hope for a
> neat ending.  Additional agreement phases will just make things uglier.
>  And a single bit of state for a single-agreement-phase protocol is much
> simpler than issues like this.

Eric,

That's a perfectly reasonable complaint.   As I previously stated, it's not 
one that particularly bothers me because I find it conceptually beautiful.
I'm thinking like a computer scientists when I say that,  not as a Go player.

The server could easily issue resolution commands until a capture is made, but 
there is always the chance that the group REALLY is safe, after all there is 
a disagreement here.    The server could also arbitrarily issue a fixed 
number of commands to minimize the extra passes.

But all of this has some ugliness in it.   I would like to propose Protocol C 
which is perhaps closer to the way humans resolve a dispute.   I have no 
illusions that this will be considered without a lot of bickering,  but I'll 
present it as just something to think about:

Protocol C works like this.   When there are 2 passes,  the server requests 
the relevant opinion from each program (either the dead stone list, the final 
score opinion,  or just plain result as David Doshay suggests.  I don't 
care.)    If they both agree, we are done.   So far, nothing has changed over 
Protocol A or B.

But if there is a disagreement,  the server issues the resolution_genmove 
command UNTIL the programs come to an agreement.   This requires that each 
program is consulted after it's move (or it could be specified as part of the 
response to the genmove_resolve command.)    

I don't believe it is  necessary to require 2 more passes for this to work.    
The game is resolved when both programs consecutively agree on the 
information requested OR when they consecutively pass.   If both programs 
pass, the score is taken AS IS.  (Alternately, a program like GNU Go could 
score at this point.  I'm not crazy about that idea,  but in this case it's 
not so bad since GNU Go won't be scoring a complicated position if your 
program executes the protocol in a reasonable way.)

When humans play,  it pretty much works just like that.  They alternately play 
moves to prove or disprove an assertion.   They stop when someone gives in 
and admits some group is alive or dead (which really means they agree on the 
whole board.)

The only thing I don't like about this is the second double pass.   But I 
don't see any way around this in ANY protocol.   It could be the best move 
for both programs even if they disagree on the results.   If it IS the best 
move for both programs,  the game is over anyone and the score is computed 
trivially.

Don








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