Thirty-ninth KGS Computer Go Tournament

Sunday June 15

These results also appear on official KGS pages: Formal Division, Open Division which link to the game records.


 Formal divisionOpen division
format6-round Swiss9-round Swiss
board size13×139×9
time18 minutes absolute13 minutes absolute


The first round started at 08:00 UCT for the Formal and 08:05 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.

We welcomed a newcomer to these events, Toaster, by Joakim Mjärdner. It uses MC with RAVE.

CrazyStone and StoneCrazy registered, but were forced to withdraw when the connection to their hardware was found not to be working.

The hardware used by the players is listed below. I present this information in the format it was sent to me: I am not qualified to understand it all.

Formal division

There were seven entrants, so byes were necessary.

In round 1, GNU playing as white against valkyria passed for move 2. The game then continued normally, with valkyria at some advantage. Valkyria eventually won. SGF

For the first round of both divisions, ManyFaces1 and ManyFaces2 both had their time management mis-configured, so as to use only two thirds as much time as was available. This may have hampered ManyFaces1, which lost to AyaMC.

In round 2, GNU was again playing as white, this time against Orego. GNU again passed for move 2, and Orego sensibly passed as well, ending the game 162½ points ahead. SGF

Before round 3, the experimental version of GNU which had played the first two games was replaced by a vanilla version. However GNU had the bye for this round.
    While ManyFaces1 was chasing and killing Orego's stones in a ladder SGF, FirstGoBot was chasing AyaMC's stones in a ladder that did not work because one of FirstGoBot's ladddering stones was in atari SGF. Both games were won by the players that read the ladders right.

AyaMC vs valkyria
The position after move 147.
In the round 4 game between AyaMC and valkyria, the position to the right appeared. SGF Black, valkyria, has just played the triangled stone, to ensure the death of the white corner. White then played at a, making the bottom right seki, and winning by 8½. If instead Black had played at a, the bottom corner would have given Black six points of territory, enough to win by 3½, as White's upper left corner would have been dead anyway.
    To a human, it is clear that the only moves worth making must be a and possibly some points in the top left; and a little reading shows that the white group in the top left is dead already – anything that White tries there can be answered by filling the white group's outside liberty.

In the round 5 game between GNU and FirstGoBot, when both players first passed, FirstGoBot was ahead by 5½ points. SGF There was then a disagreement about the status of some dead black (FirstGoBot's) stones, and the game entered clean-up mode. GNU did not try to capture any of these, nor some more dead stones which FirstGoBot added, so the game is recorded as a win for FirstGoBot by 37½. I don't know what went wrong here: GNU normally plays the clean-up reliably.

AyaMC vs GNU
The position after move 57.
In the round 6 game between AyaMC and GNU, the position to the left appeared, with White, AyaMC, to play. SGF. There is a semeai involving the two triangled groups. Each group has three liberties, and White can win the semeai by playing at a (and finding the throw-in if Black blocks). However White played at b, and lost the semeai.
    White still won the game, so it is possible that it knew that b was good enough to ensure winning the game. But I am doubtful: the top of the board is far from resolved.

Open division

ManyFaces2 vs StoneGrid
The position after move 59.
In round 1, ManyFaces2, playing white against StoneGrid, was to play in the position shown to the left. SGF It chose to play at a, which neither saves the group it enlarges, nor lives the group in the bottom left. At the time I thought that b or c, abandoning the dead stones and settling the corner group, would have been better. But examining the position more closely, I see that either way, Black will have enough ko threats to win the ko in the top left, and this will be decisive. Eric Boesch has pointed out that ManyFaces2 went wrong at move 56: if this had been at g2 instead of f4, White would have been ahead.
    At the end of the game, when both players had passed in turn, they failed to agree on the removal of the dead stones (even though there were no dead stones). This caused the game to "hang" on the server, and I was obliged to assign the result (a win to Black, StoneGrid, which was 9½ points ahead) and to kill the game (so that the bots would not try to rejoin it rather than playing in the next round). This turned out to be the fault of ManyFaces2, see below.

ManyFaces2 vs SimpleBot
The position after move 42 (pass).
In round 2, ManyFaces2 played white against SimpleBot. SGF In the position shown to the right, both players passed, and then, naturally enough, disagreed about the extent of the territories. They entered clean-up mode succcessfully, and continued play until the territories had been walled off, all dame filled, and all dead stones captured. They then failed to agree on the removal of the dead stones, so the game hung on the server again. I counted it as a half-point win to White (ManyFaces2 now incorporates some MC code, so it likes half-point wins), assigned the win, and killed the game, as in the previous round.
    David Fotland eventually identified the problem. His ManyFaces2 was able to submit a non-empty list of dead stones correctly, but was getting the syntax wrong for an empty list, sending "\n\n=\n" instead of "\n=\n\n", causing the server to wait indefinitely for the final "\n".

ManyFaces2 vs HBotSVN
The position after move 77.
In round 3, ManyFaces2 played white against HBotSVN. SGF ManyFaces2 was to play in the position shown to the left. It can win easily by connecting at the top. But it had passed repeatedly in the game so far, it had ten more prisoners than HBotSVN, and it thought (wrongly) that it was using Japanese rules. It therefore passed, believing that this was good enough to win. HBotSVN captured two stones, and attained a won position (under Chinese rules).

The same happened in round 4. ManyFaces2 got a clearly won position, and 15 prisoners, against IdiotBot, and then passed repeatedly while IdiotBot lived some dead stones and won. SGF The game-end, with the players agreeing that there were no dead stones, went correctly, showing that David had fixed the earlier bug. He now realised that ManyFaces2 was set to use Japanese rules, and corrected that too.
    AyaMC2 lost on time in a won position against SimpleBot. SGF

In round 5, AyaMC2 had some problem, and joined its game against HBotSVN but did not move. Eventually its operator woke it up, but it was now short of time, and lost on time. SGF

ManyFaces2 vs AyaMC2
The position after move 35.
For round 6, AyaMC2 was transferred to a different and maybe more reliable computer. It was late in joining its game with ManyFaces2, but played well, finding the triangled move in the position shown to the right. This kills the white group. SGF ManyFaces2 later resigned.



Processor numbers, power, etc.

AyaMC and AyaMC2
Aya, running on Xeon X5355 2.66GHz 2CPU (4 cores on 1CPU, so 8cores) and on Core Duo T2400 1.83GHz 1CPU (2 cores on 1CPU, so all 2 cores) respectively.
running on a Pentium 4, 2.67Ghz (single processor)
GNU Go, running on one core of a dual core AMD Athlon 64 processor running at 2.2 GHz.
Rounds 1-6: HouseBot 0.7 r761 running on a virtual machine on a box with a 2GHz Intel Core Duo.
Rounds 7-9: HouseBot 0.7 r763 running native on a Dual Core T2330 (1.6GHz/533Mhz FSB/1MB cache).
running on one cpu of a dual core AMD Athlon.
ManyFaces1 and ManyFaces2
Many Faces of Go, each running on one processor of a 2.4 GHz Core Duo.
GNU Go with UCT enhancements, running on one core of a dual core AMD Athlon 64 processor running at 2.2 GHz.
running on a Mac using two 3 GHz Dual-Core Intel Xeons (hence 4 cores altogether).
running on one cpu of a dual core AMD Athlon.
John Fan's StoneGrid, running on an Intel Core 2 Duo L7700 1.8GHz.
running on P4 3GHz - 2 cores, 1GB RAM.
running on a single processor Pentium M, 1.4 Ghz.
running on one cpu of a dual core AMD Athlon.