[computer-go] I know we disagree,but I choose to do nothing about it.

[drd@xxxxxxx]

Hi Nick,

I changed the subject line of our discussion, you will see why in a moment.

I thought the William Shubert protocol had already been implemented for rated 
games?   I have that in my bot and I believe it is correctly implemented.  

At any rate,  I would be happy to participate in the test tournament as it 
would be a good opportunity to test the protocol.     My program responds to 
"kgs-genmove_cleanup" by playing the game out and it actually won't pass 
until the game is completely played out.     (Actually,  a bot should not be 
in a hurry to resolve it's own dead stones, only the opponents, but my 
program does.   I'm going to change that eventually even within the 
protocol.)


I think what you say in the following quote is the way it should be:

> (1, 2, 3a.)  as above.
> (3b.)  If they disagree, the "kgs-genmove_cleanup" is issued.  The
> well-behaved bot then sets about capturing all its opponent's dead
> stones, while the old-style bot passes, or fails to respond, or does
> something unhelpful.  Eventually, the game probably gets awarded to the
> well-behaved bot.

Yes.  This is good.   I don't view it as "well behaved" or not,  I see it as 
the bot that played the best.   If your opponent thinks his stones are alive 
and you think they are dead,  isn't it counter-productive to pass?  

You are confused by my position on whether kgs-genmove_cleanup should be 
required or not.     I didn't mean for this to happen.   

The key observation here is that I can implement kgs-genmove_cleanup simply by 
aliasing it to "genmove".    Any programmer can do this.   In this case you 
have a program that recognizes kgs-genmove_cleanup but doesn't actually 
respond in any useful way.    I don't think it's reasonble to try to actually 
MANDATE that a program responds in a useful way.    After all,  what you are 
suggesting is that we make it illegal to pass under some tournament 
situations which seems kind of ludicrous to me.

But that by no means prevents the WMS protocol from being implemented.   The 
server merely pretends that it issued a kgs-genmove_cleanup command to a 
non-conforming engine.   Another way to put this,  is to say that if an 
engine doesn't respond to kgs-genmove_cleanup,  it is "implicitly" saying, "I 
know we disagree, but I choose to do nothing about it."   

And in a similar way, if a program recognizes the command but doesn't respond 
in a useful way, it is saying, "Yes, I hear you but I choose to do nothing 
about it."

This is another way of saying that you can force a program to RECOGNIZE 
kgs-genmove_cleanup,  but you don't have any say about the implementation.    

So why mandate it?        

The only slight argument in favor of REQUIRING this command to be implemented 
is that it might serve as a kind of explicit contract between the tournament 
organizer and the programmer.   If a program chooses not to do the cleanup 
stuff and loses as a result,  any logs show that the command was issued,  the 
program was duly informed of the problem and chose to do nothing about it.
It's like signing an agreement.     I think this is a fairly silly reason to 
require it,  but perhaps it has a useful purpose.

- Don  




On Friday 22 July 2005 2:04 pm, Nick Wedd wrote:
> This is a long and rambling posting.  As I write it, I am confused about
> some of the issues.  So if you cannot follow it, it is my fault, not
> yours:  I have misunderstood something, or explained it badly, or both.
>
> At present, in the Computer Go Tournaments that I run on KGS, the
> game-end procedure is as follows.
>
> (1.)   The game continues until both bots pass on successive turns.
> (2.)   Each bot makes an assertion about which stones are alive.
> (3a.)  If they agree, the game is counted by KGS scoring software, and
> the result automatically goes through to the KGS tournament software.
> (3b.)  If they disagree, the tournament organiser (which so far has
> always been myself) decides which groups are alive, counts the score,
> and presses the big button on his tournEditor program.  This overrides
> any opinions that the bots and the KGS scoring software may have, and is
> accepted by the KGS tournament software.
>
> Now, this is obviously not ideal.  I don't mind the work involved, it is
> not difficult.  But it is possible that some day a position will arise
> which is difficult to score, and I will get it wrong.  I would prefer to
> avoid this.
>
> William Shubert (wms), who runs KGS, has proposed an alternative scheme.
> As I understand it, it goes like this:
>
> (1, 2, 3a.)  as above.
> (3b.)  If they disagree, KGS issues a command to each of the, saying,
> "sorry, you are invited to carry on playing.  And now, any stones still
> on the board after successive passes will be counted as alive."  It
> decides (I don't know how) which one should move next, and tells it.
> (4.)   The game continues until both bots pass on successive turns.
> (5.)   The KGS scoring software counts the score assuming that all
> stones still on the board are alive, and the result automatically goes
> through to the KGS tournament software.
>
> This does not happen yet, because
>    (A.)  The kgsGtp interface, through which all bots connect to KGS,
> does not yet support the passing of this command to the bots.
>    (B.)  No bots yet respond appropriately when this command is issued.
>
> Now, (A.) has been addressed.  wms has provided me with a version of
> kgsGtp.jar which _does_ handle the "kgs-genmove_cleanup" command.  It is
> a beta version, and has not yet been tested.  I am not making it
> generally available, because I fear that this might cause confusion.
> However I will email it to anyone who explicitly requests it and appears
> to understand why he wants it, and that it is a currently unsupported
> beta version.
>
> This version of kgsGtp.jar needs testing.  Peter McKenzie and "Aloril"
> have both agreed to help with the testing, connecting their bots to the
> beta version of the KGS server, to play in a mini-tournament for test
> purposes.  I can also cause GNU Go to take part.  Other volunteers will
> be most welcome.
>      Note that what is being tested here, as far as wms and I are
> concerned, is the protocol, and the new version of kgsGtp.jar which
> should handle it.  If Peter and Aloril, and others, want to use the
> opportunity to also test various versions of their bots, which handle or
> fail to handle the "kgs-genmove_cleanup" command in various ways, that
> is fine with us.
>      A snag with this is that I do not have the power to create a
> tournament on the beta server, as I do on the main server.  wms will
> have to create the tournament and enter the bots that are to play in it.
> And he is, I understand, particularly busy at present, as well as being
> asleep during the hours when us Europeans decide it would be good to
> have a tournament soon.  No doubt we will soon find a way of getting
> round this (although not until August, I am off to Prague soon).
>
> A more serious problem, in my opinion, is that the bots that enter these
> tournaments do not support this game-end protocol, or do not support it
> correctly.  And I don't think it is going to be easy to get them to
> support it.  While I have huge respect for the ability of computer Go
> programmers to accomplish very difficult tasks, I am somewhat sceptical
> about the ability of some to perform mundane tasks correctly.  If you
> have read my tournament reports at
> http://www.weddslist.com/kgs/past/index.html you will understand why I
> am sceptical.
>      Now, what will happen if I require support for the game-end
> protocol, and some bots which enter the next tournament fail to
> implement it, or fail to do so correctly?  As I understand it, here is
> what will happen if one implements the game-end protocol correctly and
> the other doesn't:
>
> (1, 2, 3a.)  as above.
> (3b.)  If they disagree, the "kgs-genmove_cleanup" is issued.  The
> well-behaved bot then sets about capturing all its opponent's dead
> stones, while the old-style bot passes, or fails to respond, or does
> something unhelpful.  Eventually, the game probably gets awarded to the
> well-behaved bot.
>
> As tournament organiser, I then have two options.  I can accept the
> result and let the well-behaved bot keep its win.  This has the
> advantage that it will act as an incentive to programmers to implement
> the game-end protocol correctly.  But it will also annoy people who have
> so far failed to implement it correctly, maybe to the extent that they
> stop taking part.
>      Alternatively, I can override the result manually, as I do at
> present.  This will be slightly harder than it is now, as I will have to
> step back through the game to the point where the first two successive
> passes were made.
>
> This whole issue has already been debated here at length, in a thread
> titled "Re: [computer-go] Third KGS tournament: game-end protocol".  I
> started by being opposed to making support for the game-end protocol
> compulsory, wanting to introduce it gradually and voluntarily, or not at
> all.  However I was persuaded by Don Dailey that it was a good thing and
> its support should be made compulsory (or rather, the rules changed so
> that bots not supporting it were very likely to lose).
>
> Don then totally confused me with this exchange:
>
> NW> I have been persuaded by posters to this list that I should
> NW> eventually require bots playing in KGS computer Go tournaments to
> NW> support the game-end protocol.
>
> DD> I think there is a misunderstanding here.  This should not be a
> DD> requirement.
>
> DD> According the rules of Go, a player can pass whenever he wants to.
>
> DD> kgs-genmove_cleanup is just "genmove" with a request attached to it.
> DD> The request is, "please try to capture your opponents dead stones."
>
> DD> It is up to the program whether it wants to honor this request,
> DD> because it is not illegal to pass.
>
> DD> Therefore the kgs-genmove_protocol command is a request at best, not
> DD> an enforcable demand (according to the rules of GO anyway.)
>
> DD> That's why this whole business of having a human step in to clean up
> DD> the results is so unatural and ugly (in my opinion.)
>
> Don seems to me, here, to start by saying that support for the game-end
> protocol should not be a requirement;  and to end by wanting to get rid
> of the human intervention step (which is necessary if the game-end
> protocol is not supported).
>
> Nick
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/