Re: [computer-go] Protocol B

["Eric Boesch" <ericboesch@xxxxxxxxxxx>]

John says that if Protocol B gets ugly when one side plays Tromp-Taylor, 
it's that player's fault.  The point isn't that the programmer implements 
Tromp-Taylor, ignoring the agreement phase, to be rude -- the programmer is 
just handling the endgame as simply as he can, by solving all disputes over 
the board.  Unlike playing on as long as possible, that is not *inherently* 
ugly.

drd@xxxxxxxxxxxxxxxxx writes:
> This protocol is for Chinese playing,  not Japanese.    It's broken if a
> program plays Japanese.
Now Don says the ugliness is the fault of the side that plays 
territory-rules style?  But as I understand it, that's what David liked 
about this protocol:  his program could pass as many times as it wanted, 
except when it received a genmove_resolve_dispute and was forced to play a 
stone.

Not all protocols are broken if one player plays area rules while the other 
plays territory rules.  The current KGS rules allow exactly that -- that's 
their strength.  If a program plays by area rules and fills all dame at the 
end of the game, it has also filled all valuable points by territory rules.  
Yes, there are other differences between Chinese and Japanese relating to 
seki eyes and ko, but that's a different and relatively minor issue.

Protocol B is broken *whenever* the two players disagree, unless the players 
are designed to compensate for the protocol's weakness by treating all 
genmoves after the first genmove_cleanup like genmove_cleanups, in which 
case the protocol is identical to single-agreement-phase.  If the players 
disagree at move 180, they almost certainly will disagree at move 181, 182, 
183..., until finally, at say move 200, they finally have resolved their 
difference.  This is especially true if the protocol doesn't even allow the 
players to know which group or groups the disagreement applies to (not that 
I would expect anybody to bother writing a special interface to resolve 
*just one* group's status -- as opposed to all of them -- over the board 
anyhow).

In the meantime, the players will play a molasses game.  John simply assumes 
the many extra passes and resolution phases will take negligible time.  
Resolution certainly doesn't take negligible time when people do it.  Some 
programs might do it faster, but others might read carefully and do it 
slowly -- the same applies to the passes that precede the agreement phases, 
which take time off the real clock whether or not they take time off the 
game clock.

The agreement phase *should* be a minor part of the game.  If I could make 
it fast enough to run once, then that is good enough to satisfy human 
opponents.  If I had to make it run fast enough to be run many times in 
order to satisfy Protocol B, and I couldn't do that easily, then I would 
ditch it in favor of the "I win!" nonagreement function for that tournament, 
and if the protocol makes the consequences much uglier than they have to be, 
I would not blame myself for that.

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.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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