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

Re: [computer-go] Protocol B



This protocol is for Chinese playing,  not Japanese.    It's broken if a 
program plays Japanese.     But if 2 players sit down and one is playing 
Japanese and one Chinese,  then it's a problem anyway, you have the 
equivalent of a disagreement on the end game protocol before you even begin.

Don


On Thursday 28 July 2005 2:32 am, Eric Boesch wrote:
> Protocol B looks a lot like Chinese agreement to me, but I think that makes
> a bad choice for computer go.  The reason is this scenario, which I
> consider likely:
>
> Black's program plays Japanese-style.  Presented with a "genmove" command
> in a situation where all moves lose points by Japanese rules, black will
> pass. Only if presented with a "genmove_cleanup" command (or a
> "resolve_disagreement_genmove", which seems like the same thing) will black
> try to capture dead opponents' stones.  This is certainly reasonable.
>
> White's program does the very minimum, interface-wise, that is required to
> avoid throwing games.  For simplicity's sake, white is hard-coded to be
> stubborn during agreement phases -- "I win; my stones all live, your stones
> all die" -- so the agreement phase is a waste of time where this program is
> concerned.  Before passing even once, white will capture all opponent
> stones; this allows white to treat genmove and genmove_cleanup the same.  I
> think this is fair too, even if it's not so stylish.
>
> What happens when these two programs play under a protocol that allows an
> arbitrary number of agreement phases?  At some point, the last real point
> on the board is taken, but both sides may have dead stones left on the
> board. After that, in keeping with their programming, black passes
> repeatedly while white captures black's dead stones.  When white captures
> black's last dead stone, things get bogged down:
>
> 1. KGS sends genmove to black, who passes
> 2. KGS sends genmove to white, who captures black's last dead stone.
>
> 3. Genmove: b passes
> 4. Genmove: w passes
> 5. Agreement phase (fails)
>
> 6. Genmove_cleanup: b moves to capture a stone
> 7. Genmove: w passes
> 8. Genmove: b passes
> 9. Agreement phase (fails)
>
> 10. Genmove_cleanup: w passes
> 11. Genmove_cleanup: b moves to capture a stone
> 12. Genmove: w passes
> 13. Genmove: b passes
> 14. Agreement phase (fails)
> 15. Repeats from step (10) until all white stones are captured
>
> 16. Genmove_cleanup: w passes
> 17. Genmove_cleanup: b passes
> 18. Game ends.
>
> The endless attempts at agreement turn pairs of moves (white passes, black
> places a stone) into four moves plus an agreement phase.  If you're going
> to have dozens of agreement phases then you have to be careful about time
> controls for those phases too.  I think that is so ugly that it's a
> non-starter.  I'd prefer almost anything else, from Tromp-Taylor to human
> adjudication.  If you prefer your area rules to have an agreement phase
> (unlike Tromp-Taylor) so your program can indicate where it thinks the game
> "should" end, then great -- but only one, please.  If the first agreement
> phase doesn't work then the others probably won't work either, especially
> with computers that aren't as adept as people are at identifying and
> resolving specific points of contention.
>
> >From: drd@xxxxxxxxxxxxxxxxx
> >Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> >To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> >Subject: Re: [computer-go] Protocol B
> >Date: Wed, 27 Jul 2005 22:20:36 -0400
> >
> >Hi David,
> >
> > > (pass - pass)
> > > ?score?
> > > if agree
> > > 	no problem, game over
> > > if disagree
> > > 	resolve-disagreement-genmove
> > > 	if reply is pass
> > > 		resolve-disagreement-genmove
> > > 		if reply is pass
> > > 			game over, everyone alive
> > > 		if reply is not pass
> > > 			continue game with genmove
> > > 	if reply is not pass
> > > 		continue game with genmove
> > >
> > > What do others think?
> >
> >I like that.   I also agree that this protocol is superior.
> >I'm not overly concerned with whether the agreement is about score or dead
> >stones,  I'm happy with either.
> >
> >I'm not sure it is absolutely necessary to have the special
> >resolve-disagreement-genmove command, since a program can infer this from
> >the
> >fact of multiple passes.    But I can see why some might feel it is better
> >to
> >be explicit.   It seems slightly cleaner and simpler not to have the extra
> >command but it's nothing I would lose any sleep over either way.
> >
> >Don
> >
> >_______________________________________________
> >computer-go mailing list
> >computer-go@xxxxxxxxxxxxxxxxx
> >http://www.computer-go.org/mailman/listinfo/computer-go/
>
> _________________________________________________________________
> Don’t just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/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/