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

Re: [computer-go] Protocol B



This can be nitpicked forever.   I think it's completely unfair to suddenly 
consider it a flaw in the protocol if a program is playing by Japanese rules  
in a Chinese tournament.     After all, to be perfectly fair,  wouldn't a 
Chinese program be severely penalized playing in a Japanese style tournament 
if it was designed for Chinese rules?     Perhaps we should propose than in 
Japanese tournaments,  a program must not be penalized for making needless 
extra moves because it "might" think it is playing Chinese?

There is simply no point in bringing this to the table.   If it's possible to 
make this protocol work for Japanese style tournaments,  that's great.  But 
only for programs that are expected to be playing by Japanese rules.

Your point on having a large number of resolution phases is far more 
interesting and valid in my opinion.   A series of moves near the end of the 
game could go like this:  pass - pass - move - pass - pass - move - pass - 
pass ... and so on.   

But this is just the resolution phase, not the game itself.  It  doesn't 
particularly bother me.   If such a protocol is ever adopted, I will make my 
program maintain the resolution phase a few extra moves, perhaps to the first 
interesting capture or something.    I would do this so a malicious program 
couldn't beat my program by playing like this rapidly to run up the number of 
moves.

It seems like a whole lot of discussion is based on this concept of trying to 
avoid responsibility for anything.   If there are malicious things that could 
be done,  they WILL be done by someone at some time but you have to take 
responsibility for defending yourself.    If another program runs your 
program out of time,  shame on you for letting it happen (unless they did it 
illegally, then shame on them.)     If you lose a Japanese tournament because 
you played Chinese, it's your own fault.  You are a dummy for filling in your 
territory when you knew it was a Japanese tournament.   The same applies for 
the situation where you enter a Chinese tournament with a program that 
doesn't know this.    If I'm playing in a tournament with Ko rules that are 
different than the ones I implement in my program,  and it gets kicked out 
for making an illegal move,  who is to blame?  

Don
 




On Thursday 28 July 2005 9:36 am, Eric Boesch wrote:
> 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/
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/