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

Re: [computer-go] Protocol B



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/