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.
> This is annoying for the other competitors.  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.  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.
>
>
>
> > 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 do not
> expect you to be appeased by this.
>
>
>
> > I consider it a bug in kgs that
> > this perpetually gets misinterpreted by spectators.
> >   Please stop saying that my bot insists all of its stones are alive.
> > This could be simplified by either fixing the game end protocol rules,
> > or getting kgs fixed (kgsGtp and/or the server).
> >
> >   In the round two game, it was HBotSVN that had 3 seconds left on the
> > clock.  Its opponent, MonteGNU, had almost a minute left (51 seconds).
> >
>
>  Thank you for pointing this out.  I have corrected my mistake.
>
>
>
> > The only games where HBotSVN's opponent got down to very little time
> > left was the game against Leela.
> >   The whole probation thing has really pissed me off.  Maybe one
> > component of that is first finding out about it by reading it in the
> > report.  I have not been implementing "difficult things" for quite a
> > while.  Because stuff wasn't working, I suspended all forward progress
> > on my bot two months ago.  Since then, I've been building test
> > harnesses, writing unit tests, and eliminating bugs.
> >   Did you know that weakbot50k and idiotbot don't actually handle the
> > game end at all?  Once both players pass, they switch to using gnu go.
> >
>
>  I didn't know that, but it seems a sensible, robust, solution.
>
>  Nick
>
>
>
>
> >   I will no longer participate in these tournaments for the foreseeable
> > future.

I fail to see the problem with HBotSVN's behavior.  It is playing
according to the protocol as specified.  Humans judging intent and
reasonableness belong in human tournaments, and possibly
human-computer tournaments, but most emphatically not in
computer-computer tournaments.  What would you do if HBotSVN
implemented final_status_list dead and always returned the empty set?
What if it only returned stones that were unsalvageable even in the
face of opponent passes?  HBotSVN seems to be requiring its opponents
to demonstrate that they are actually capable of killing the groups
they claim are dead.  Given the skill level of some programs, and that
programs are not offendable, this behavior seems at worst mildly rude,
possibly deserving of derision and disrespect, and completely
undeserving of any sort of sanction.

It is entirely within the power of the other bots to not lose on time.
 If they cannot manage their time, that should be viewed as a defect
no different from not being able to manage sente.  If you dislike the
effect this has on time management, add a single 1-3s byo yomi period
(or some other time system; I dislike Japanese byo yomi but it works
well enough here and is traditional).  Any program that cannot play
out the dispute resolution accurately in 1s byo-yomi had no business
being so confident in its assessment that it should run out all its
time before passing.

Attitudes like this make me think that these games are to be taken
solely as exhibition games, and not as actual tournaments.  I find
this disappointing, as I think KGS could be a good complement to CGOS
as a forum for computer Go.

Someday I hope to return to writing a computer Go program.  However, I
can't see myself entering it in any tournament that does not precisely
and accurately specify the required behavior.

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

Reply via email to