[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Protocol B
Hi Peter,
The status command is already a GTP command and every program knows when it
wants to pass, it's a by-product of the search. I'm just suggesting the
command is sent after each search. Or it could be sent as part of the
responds to the genmove_resolve command. The engine sends the move followed
by the score it believes to be correct.
Remember, none of this happens until both programs have already agreed that
the game is over (even if they disagree about the results.) Certainly
they should be ready to compare notes, isn't that what humans do?
And everyone wants a human like protocol, this is about as human like as you
can get. When humans are resolving they essentially play out of few moves
until they agree. They don't double pass again to agree, it's not that
formal.
Essentially, the first set of double pass moves should end the game, and
after that we are in a resolution phase. There is no need for double pass
after this, it is just a signal to compare notes again. So why bother with
the formality? We can easily just play on until both programs agree without
all the passing.
Even for a well behaved program that would like to pass, this saves times
because you can avoid wasteful passing if you KNOW the opponent is confused
about the score.
Don
On Friday 29 July 2005 9:24 am, Peter McKenzie wrote:
> >From: drd@xxxxxxxxxxxxxxxxx
> >Reply-To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> >To: computer-go <computer-go@xxxxxxxxxxxxxxxxx>
> >Subject: Re: [computer-go] Protocol B
> >Date: Fri, 29 Jul 2005 08:22:56 -0400
> >
> >
> >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.
>
> Isn't the problem here that it may result in a large number of status
> commands being sent? And it seems likely that the status command (whether
> it be requesting the score or a dead stone list) will have non-trivial
> execution time for some if not most programs.
>
> >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/
>
> _________________________________________________________________
> Looking for love? Check out XtraMSN Personals
> http://xtramsn.match.com/match/mt.cfm?pg=channel&tcid=200731
>
> _______________________________________________
> 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/