[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] 2nd KGS Computer Go Tournament
In message <1115747325.11213.19.camel@xxxxxxxxxxxxxxxxx>, William M.
Shubert <wms@xxxxxxxxxxxxxxxxx> writes
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.
Where can I find the full spec?
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?
Yes. Indeed, I was there to do precisely that at the London Open late
last year. In fact weak players rarely asked me to help them,
preferring to mangle things in their own ways. But I was asked to count
their game by two strong Chinese players, who did not know how Japanese
counting worked. I don't think anyone would suggest that they should
have been penalised for not knowing Japanese scoring.
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.
Maybe it's not finished, but it's good enough. How about all the human
players who use Japanese rules without knowing how to apply them - the
huge majority?
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 am happy to babysit. It is the least arduous of my duties.
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.
Nick
--
Nick Wedd nick@xxxxxxxxxxxxxxxxx
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/