| Formal division | Open division | |
|---|---|---|
| format | 6-round Swiss | 9-round Swiss |
| board size | 13×13 | 9×9 |
| rules | Chinese | Chinese |
| komi | 7½ | 7½ |
| time | 28 minutes absolute | 18 minutes absolute |
The first round started at 08:00 UCT for the Formal and 08:10 for the Open division.
As usual, the tournament was held in two divisions, Formal and Open, with more restrictive entry conditions for the Formal division.
Formal Division 13×13
|
Open Division 9×9
|
The "real" names of the bots listed above, and of their programmers, are listed here: programs which have registered for KGS Computer Go Tournaments.
CzechBot is a build of MoGo, entered by Petr Baudiš. I agreed to accept its registration, but to remove it if an "official" MoGo entered.
Hb06 "is a much more modern revision of housebot than HB04", by Jason House.
In round 5, agog2 had a secure win against GNU by move 85; there were several dame left,
agog2 only needed to take one of them to win, and it had over five minutes left on its clock.
It duly claimed one of the dame, then both programs made pointless moves until agog2 only had
11 seconds left, when they both passed in turn. However they failed to agree on the status of
agog2's four eyeless groups, so play resumed. If agog2 had now passed rapidly, it might still
have won. But it preferred to prolong the game by creating further eyeless groups, and lost
on time.
It is at first surprising that a program which can do thousands of roll-outs per second, can
still spend up to eight seconds choosing which completely worthless move to make when no move
has any value at all. But I can see how this arises from use of UCT. I don't know what a proper
solution is. But a cheap fix which would have worked for this game is "if all moves lead to the
same result, then pass". Another would be "if your group dies in every roll-out, concede that
it is dead."
|
|
|---|
| GNU vs. valkyria19 |
In round 5, break, though connected to KGS, did not join its game against WeakBot50, and timed out.
In round 7, hb06 went to sleep in its game with CzechBot, and eventually timed out.
In round 8, hb06 connected to its game with SimpleBot, or at least its client program did. But it made no move, and eventually timed out.
In round 9, the same happened in its game with WeakBot50k. Jason House has explained: "HB06 hung in round 7, never responding to a genmove command. Since the bot didn't crash, kgsGtp never disconnected since it was patiently waiting for a response from the engine. The hang up in round 7 therefore carried over into rounds 8 and 9 causing losses on time vs. SimpleBot and WeakBot50k without ever making a move."
Situations like this used to give me a problem. As an admin, I have the power to "kick" a user. Kicking is intended as a mild punishment for human users who misbehave. But the effect of kicking a bot that has gone to sleep is often to wake it up; with the disadvantage that it cannot reconnect for five minutes. I was somewhat reluctant to use it, as I could rarely be sure that it had really hung, and I did not want to be resonsible for destroying five minutes of its time, particularly when there were short time limits. But kicking a bot that timed out of a game, when there was more than five minutes to the next round, was sensible.
Then, thanks to a bug that appeared in the server code, this problem (for me) went away. The effect of the bug was that when an admin kicked someone, it was the admin that got removed from the server, the misbehaving user was unaffected. I no longer had the option of trying to wake a bot by kicking it. I got out of the habit of considering "kick" as an option.
But recently, this bug was fixed. I can now kick users again, and would have kicked hb06 if I had thought of it. I will always be willing to kick a bot if its operator explicitly requests it; and I can take requests at registration time to kick a bot that has been inactive for a period specified by the operator. But in the absence of both instructions and operator, I think I shall kick any bot that times out of a game.