On Wed, May 7, 2008 at 11:45 AM, Nick Wedd <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, > Jason House <[EMAIL PROTECTED]> writes > > > Correction: HBotSVN was not reconfigured for speed in round 3. It was > > set to use two search threads in round 4, and was compiled in debug > > mode for the whole tournament. I apologize for the confusing PM's > > during the tournament about this. > > > > Thank you for explaining this, I have changed the report accordingly. > > What is "HBotSVN's technique"? > > > > Its technique is to refuse to admit that its dead groups are dead, and > then to waste time in the resolution phase playing meaningless stones. This > sometimes gives it a win on time, and is the only way that it wins games. That may be true on larger boards since my bot is MC-based and lacks the move quality heuristics that the stronger MC bots have. The last 9x9 tournament with HBotSVN in was back in November. It won 5 games. I know it is not your intention that it behaves like this, but it is in your > power to prevent it. It is not in my power to do anything about it, except > by reassigning the results of games which it wins like this: this is the > purpose of the probation. Many things are within my power, but the bigger question is what functionality should I invest my time to? I feel that my time is best spent trying to (fairly) win games instead of losing games with style. My bot's behavior in endgame has not changed in a long time, but suddenly isn't acceptable anymore. Specifying the rules of the tournament is within your power. If supporting "final_status_list dead" is a requirement, then say so. The only thing I can expect is for the rules (and you) to be consistent. If you will adjust game outcomes using judgment, then do it for any game where it's appropriate. Enforcing rules inconsistently or making up transient policies to fix something that caught your attention really isn't fair. > It is in Bill Shubert's power to change the way the server works so that > if only one player sends a final_status_list, it will accept what that > player says. I shall suggest it to him. Also having an engine that does not support final_status_list add a comment in the game, similar to when a disagreement in scoring occurs would also be good to have. > > The game end protocol says "To play > > in a tournament, programs must either implement both > > "kgs-genmove_cleanup" and "final_status_list dead", or they must play > > until all of their opponent's dead stones are removed from the board. > > It's OK if "play until dead stones removed" is an option, but they have > > to make sure that this option is turned on whenever they are going to > > be in a tournament, or they will do poorly in the tournament!". > > HouseBot (HBotSVN) handles this by playing until all of its opponent's > > dead stones are removed. > > "final_status_list dead" is not supported. It's kgsGtp (not > > HouseBot!) that insisists that all stones are alive. It annoys me > > every time I see the description that it's the bot that's behaving > > badly when it's really a problem with how the combination of kgsGtp and > > the KGS server represent this stuff. > > > > I have changed the wording of my report from "claimed they were alive" to > "failed to admit that they were dead". I have done so because you have > persuaded me that it is correct and what I said before was wrong. I'm happy to hear that you fixed it. I hope it'll also help other immature bot entrants into the tournament. > I do not expect you to be appeased by this. I don't know why today's report bothered me so much. Small facts to fix are normal things, and I appreciate all the work you go through running these tournaments and writing up the reports. While in practice the probation thing is really nothing, it feels more like I'm being slighted. I can understand your position, I just really don't like how it was handled.
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
