Sixty-third KGS Computer Go Tournament

Sunday September 5th 2010

These results also appear on an official KGS page which links to the records of all the games.


format20-round Swiss
board size9×9
time4 minutes plus 25/60s


The first round started at 16:00 UTC.

Result table


Seveteen players registered.

Normally, when an odd number of players is registered, I remove IdiotBot (with its operator's approval), so as to make the number of players even and avoid byes. But one of the players registered, break9, was not present half a minute before 15:58, when it would become impossible to change the list of players. Break has been unreliable in the past, so I removed break9 and left IdiotBot in the draw.


At the end of round 5, every player had lost at least one game. Four players, EricaBot, ManyFaces1, pachi and PueGo were tied on four wins.

In round 11, PueGo failed to join its game with coldmilk, and timed out. Its operator reported these messages:

"FINE: Game is over and scored (final result = W+88,5), leaving game."
"FINE: Tournament game found, will join"
"WARNING: Already had a game in play! Can't join tournament game."
"FINER: No games to join. I'll just sit and wait."

This is evidence of a bug somewhere, I suspect either KGS or the kgsGtp interface, causing PueGo to be told that it was already in a game when it wasn't.

At the end of round 13, EricaBot and ManyFaces1 shared the lead on 10 wins.

PueGo vs ManyFaces1
Position after move 67.

In round 14, playing against ManyFaces1, PueGo suffered a similar problem to the one in round 11SGF. Its operator restarted it, and it was able to start playing in its game, but only after losing 140 seconds (out of a total of 240) to the bug.
       Late in the game, in the position shown to the right, PueGo as White did not respond to the marked move by trying to save its upper right group, instead it played a (pointless) move in the lower left. This surprised me; but on checking after the tournament, I found that it had no way to save the upper right group. It must have read this out during the game, despite being short of time.

EricaBot vs valkria
Moves 56-60.
59 captures 56.

In round 15, EricaBot and valkyria played as shown to the left SGF. Move 57 seems surprising and purposeless, playing at 60 to connect all the black stones together looks better. But valkyria had calculated that this would bring about an endgame in which EricaBot would win by half a point. Its only chance was to try to win the ko at the top right, and if White played at 60, to try to win the semeai at the top as well. So 57 was a sensible ko threat.
       Unfortunately for valkyria, it had no way to win the resulting semeai.

After round 18, EricaBot, ManyFaces1 and PueGo were tied for the lead, each with 13 wins from 18 games. (PueGo might have had a clear lead, had it not been the victim of the bug that caused it not to join its games, described above.)

In round 19, EricaBot beat Zen9 and ManyFaces1 beat coldmilk, but PueGo lost to pachi. This left EricaBot and ManyFaces1 leading with 14 wins from 19 games.

In round 20, EricaBot was draw to play SimpleBot, and ManyFaces1 to play gomorra9 SGF. If they had both won, ManyFaces1 would have won on SOS, as SimpleBot had only six wins compared with gomorra9's 11. However, while EricaBot won its game, ManyFaces1 lost to gomorra9.
       In round 20, cyVersion1 is shown as having forfeited its game with pachi. In fact it did nothing wrong, and resigned in a lost position. I do not know why KGS shows the game as "Forfeited".


Overall, this was an exciting tournament for the competitors and for the observers. The result, with the winner having fifteen wins and five losses, shows that things could easily have gone differently. It does not however show that fast small-board Go is random: the games were played with skill, and I believe that many of the entrants were playing more strongly than human amateur dan players. The weakest player, IdiotBot, lost all its games, showing not only that the others are reliably stronger than a very weak player, but more important, that they are generally reliable at playing legal moves within the time limits.

I appreciate IdiotBot's continuing participation in these events. It acts as a make-weight so I can try to avoid byes; it acts as an incentive for programmers whose first target is to beat it; it plays fast, honestly, and legally; and it does not mind taking the bottom place in the results table.

It is sometimes claimed that a komi of 7½, as used in these events, favours White. In this tournament, White won 81 games, Black won 79.

Details of processor numbers, power, etc.

Aya, running on i7 980X 3.3GHz 6cores
coldmilk, running on 4 cores, Core i7 920 4.00Ghz.
cyVersion1, unspecified platform.
MoGo, running on double-core AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (2.5GHz).
Erica, running on Xoen 8 cores, 2.26 GHz.
Gomorra, running with 8 threads on two Intel i7, 2.8 Ghz.
running on Linux, 2GiB RAM, Intel(R) Celeron(R) M CPU 530 @ 1.73GHz, system shared with WeakBot50k
Orego, running on one of the five nodes of a new custom Linux cluster build by PSSC Labs: AMD Six Core Dual Opteron 2427 2.2 GHz  (12 cores total), 8 GB RAM, Centos Linux
Many Faces of Go, running on four 2.3 GHz Core2 Quad (16 cores total)
pachi, running on 56 threads, 40 cores (hyperthreading enabled) mixed i7/core2 on 10 machines
Fuego, AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ on 3GHz, 2G RAM
GNU Go, running on Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz with 4G RAM.
running on one processor of a 4GiB RAM, AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
valkyria, running on a Windows 7 machine with i7-860 4 Core processor 2.8 GHz
running on Linux, 2GiB RAM, Intel(R) Celeron(R) M CPU 530 @ 1.73GHz, system shared with IdiotBot
running on a Mac Pro 8 core, Xeon 2.26GHz.