[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/