Re: [computer-go] 2nd KGS Computer Go Tournament

["William M. Shubert" <wms@xxxxxxxxxx>]

On Tue, 2005-05-10 at 14:52 +0100, Nick Wedd wrote:
> In message <1115680707.3757.48.camel@xxxxxxxxxxxxxxxxx>, William M. 
> Shubert <wms@xxxxxxxxxxxxxxxxx> writes
> >Here's my thoughts on the end-of-game scoring thing.
> 
> I am still thinking about this.
> 
> I have never programmed a bot myself, so I had to I start by reading the 
> documentation for final_status_list and kgs-genmove_cleanup.  I did not 
> find this documentation easy to find, but I am glad I had to make the 
> effort, as it has induced me to update a couple of the links from 
> http://www.weddslist.com/kgs/how/index.html and its related pages.  (You 
> may wonder why I have written these pages at all, when I am not a bot 
> programmer, not a java programmer, and don't understand their subject 
> matter.  I have done it because people of varying degrees of ignorance 
> sometimes ask me "how can I connect my program to KGS?" and I want to 
> direct them to one reasonably coherent source.)
> 
> When I had found the documentation, I did not find it easy to 
> understand.  For final_status_list it says ".. return a list of dead 
> stones ..".  Is this meant to be a list of my dead stones, my opponent's 
> dead stones, or both?  Also I have no idea what the list is meant to 
> look like, but I guess this is obvious to java programmers.

I believe that the GTP spec is fairly clear about final_status_list. In
the kgsGtp document I only try to provide annotations to the GTP spec,
explaining which commands are used and why, I don't try to repeat the
full spec on each command.

> I am reluctant to equate "not implementing the game-end protocol" with 
> "buggy".  With "defective", maybe, but not with "buggy".
> 
> I want wins to be assigned to the bot that plays best, up to the game 
> stop.  I don't want a bot to forfeit a game because it has failed to 
> implement a game-end protocol.  I would prefer them to implement the 
> game-end protocol, as defined by wms, but if they fail, I can still 
> cope.
> 
> I know that I am in a minority, among contributors to this mailing list. 
> But I see a requirement to implement this not-strictly-necessary stuff 
> as a deterrent to entrants, and I want to encourage entrants.

I'm really puzzled by this separation between "playing" and "scoring."
If you ran a human tournament, and some players were totally unable to
tell you which stones were alive and dead at the end of the game, would
you as the TD go and sit next to them after each game and figure it out
for them, then tally up their score? I think most TD's would get
impatient with this quite fast and would just demand that the players
continue playing until either a) they can say which stones are alive and
dead, or b) all dead stones are removed. Knowing how to score is part of
the game, and a program which does not know that, cannot play go. A
program which does know how to score but is not capable of expressing it
simply is not finished yet.

> If I find that three quarters of entrants have implemented wms's 
> game-end protocol correctly, or if programmers less competent than Don 
> Dailey assure me that they found it easy to implement, I will become 
> more willing to make it a requirement.

I was under the assumption that the current system, where you have to
babysit and enter final scores for some programs, wasn't acceptable. If
it is, then that's fine, I'll leave things as is, but of course the big
drawback is that there is no chance of ever having a 100% automated
tournament.

I guess I'm surprised by your answer because the feedback I expected was
alternative algorithms and systems of finding the final score. I didn't
expect "well, let's just say it's optional for programs to score the
game." But I guess since you are doing the work, if you're fine with
that, then that is fine with me.

_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/