Re: [computer-go] Protocol B

[drd@xxxxxxx]

What if we simply used Protocol B but the server continued to send the 
resolve_genmove command UNTIL both programs agree with the status?    The 
only change is that the server  issues status commands after every 
resolve_genmove in order to keep up with the programs opinions.

Don


On Friday 29 July 2005 12:42 am, Peter McKenzie wrote:
> >From: John Tromp <John.Tromp@xxxxxxxxxxxxxxxxx>
> >Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> >To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> >Subject: Re: [computer-go] Protocol B
> >Date: Thu, 28 Jul 2005 17:49:56 +0200
> >
> >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.
> >
> >Many people have expressed a preference for always play it out rules.
> >That is certainly the simplest possible protocol. But other people resist
> >this idea because it would make programs look stupid compared to humans.
>
> I think there are (at least) a couple of other reasons for the protocol to
> not use pure play it out rules:
> - speeds up automated test games (useful for those of us who run large test
> matches)
> - can possibly be used to resolve human-computer games (on the Go servers
> for example)
>
> >So there is more or less consensus that programs should be given a chance
> >to agree on the score as early as possible.
> >Protocol B is the simplest possible incarnation of this, giving the
> >programs
> >as many chances as possible to come to an agreement.
>
> I would question whether Protocol B is any simpler than Protocol A, depends
> on how you look at it of course.
>
> >I consider this to be quite human like. If two human players decide to
> >resume play to decide the status of some disputed group, then once the
> >status of that group is clear, they will try to come to another agreement.
> >
> >So if two smart programs both react to an initial dispute by resolving the
> >most likely disputed group, doesn't it look similarly stupid if they are
> >now
> >forced to play out the rest completely?
> >
> >I guess the question comes down to:
> >Do we want the protocol to cater to the most desirable program behaviour,
> >or to the most lazy/exploitative possible behaviour?
>
> Actually I think that both protocols cater very well for the most desirable
> program behaviour which is that the programs will correctly score the
> position and/or correctly list the dead stones.
>
> I'm not sure about lazy/exploitative behaviour but I do agree with Eric
> Boesch about the troublesome scenario that may easily arise.  I think that
> Eric has perhaps not sold his argument very well by referring to Japanese
> rules, as I think his reasoning applies without needing to bring Japanese
> rules into it.
>
> I see an issue with any match between two programs such that:
> - Program 1 is a 'smart' program that passes prior to killing dead stones
> - Program 2 is a 'simple' program that assumes all of its stones on the
> board are alive
>
> Consider a game between these two programs, assuming that program 2
> (simple) has dead stones on the board after both programs pass.  It is
> clear that under Protocol B there *may* be many extra commands required to
> be sent both programs in order to finish the game (over and above that
> required by Protocol A).  This has the disadvantage of possibly putting one
> or both programs under additional time pressue.
>
> The above scenario is a very real one and is certainly likely to happen
> quite often.  There is absolutely nothing exploitive about it.
>
> Does that mean I am against protocol B?  Not necessarily.
>
> As someone who is potentially the author of type 1 (smart) program, would I
> allow my program to be bombarded to a huge number of extra commands (all of
> which take non-trivial time for my program to process)?  No way!
>
> I would of course implement some logic in my program to cut down on the
> number of times that it will have to enter the game resolution phase. 
> Maybe my program will simply go into 'capture all' mode after receiving the
> first resolve-disagreement-genmove command.  But that is effectively
> reverting to protocol A which hardly advertises the merits of protocol B.
>
> There are many other approaches I could try.  For example, my program could
> stay in capture all mode until it has made a capture, or until it has
> captured N stones.  Or it could only revert to capture all move after going
> through the score resolution mode a given number of times.
>
> So, regarding the difficulty for program authors to support each protocol,
> I must change my mind again and suggest that it will be more difficult to
> support protocol B if you are concerned about time usage which I imagine
> most programmers are.
>
> Overall I could live with either protocol but I favour protocol A as I
> think it gives the best balance between features and simplicity.  It
> happily handles the best case scenario (where both programs agree on
> score/dead stones) just as well as protocol B, but doesn't have the nasty
> worst case scenario of protocol B.  Protocol A doesn't give programs a
> second chance to agree on score/dead stones but in practice I doubt that
> this is important - if they don't agree first time then I suspect it is
> likely they won't ever agree.  And lastly, Protocol A involves fewer
> complications for the program authors to worry about.
>
> Anyways, I've probably said more than enough on this issue so I'll try to
> make this one my last post on it!!
>
> cheers,
> Peter
>
> >regards,
> >-John
> >_______________________________________________
> >computer-go mailing list
> >computer-go@xxxxxxxxxxxxxxxxx
> >http://www.computer-go.org/mailman/listinfo/computer-go/
>
> _________________________________________________________________
> Discover fun and games at  @  http://xtramsn.co.nz/kids
>
> _______________________________________________
> 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/