Spring 2012 KGS Slow Computer Go Tournament

Sunday March 11th - Wednesday March 14th, 2012

These results also appear on an official KGS page.


format12-round Swiss
board size19×19
time3 hours sudden death


The first round started at 22:00 UTC.

Result table

pachi Zen19 ManyF gomor AyaMC MyGoF MCark Orego
W13R B17R W012R W12R B18R B14R W110R W11R B111R B1637½ W15R B19R 117666Winner
2Zen19S B03R W07R B112R
W14R B19R B12R W111R B15R W1852½ B11081½ W11R B16R 107755
3ManyFaces1 B02R W08R B04R W09R
W13R B16R W012R W11T B111R W17R B110R W15R 77527
4gomorra16 W04R B010R W02R B011R B03R
B17R W18R W05T B1951½ W16R W11R B112R 67421
5AyaMC B01R W011R W05R W06R B112R W07R B08R
W1470½ B12R W19R B13R W110R 67019
6MyGoFriend W0637½ B0852½ W01081½ B01T W011R B15T W0951½ B0470½
W13R B112R B02F W17R 47113
7MCark B05R B01R B07R W010R B06R W02R B09R B03R W012R
B14R W18R B111R 3643
8Orego12 W09R W06R B05R B01R W012R W03R B010R W12F B07R W04R B08R W011R

In the table above,
   0 is a loss
   1 is a win
   J is jigo
   left superscript is the player's colour
   right superscript is the round in which the game was played
   a subscript shows how the result was determined:
      R for resignation
      T for time
      F for forfeit
      a number for the points difference after counting.
All the 0s, 1s and Js are links to the game record.


In round 1, pachi2 and AyaMC played the first 20 moves very fast, both using their joseki books. AyaMC needed to think about move 21, but pachi2 was still in its book and did not need to think until move 26.

In round 2 MyGoFriend did nothing for 90 minutes in its game with Orego12. Its operator then logged in using its account and did something to resolve the problem. MyGoFriend then played normally, until Orego12 resigned in a totally lost position. The game is shown in the players' game records as a win by MyGoFriend. However MyGoFriend's operator's intervention caused it to be regarded as a loss by forfeit for MyGoFriend, for the purposes of the tournament.

Something similar has happened before with MyGoFriend. On that occasion KGS programmer 'wms' explained:

- the "W+Forf." means that this score was not based on win or loss on the board, but through other reasons. In this case, MyGoFriend logged in as a human and was promptly handed a loss. The game was not cancelled, though, so they were able to continue playing.

Looks like MyGoFriend was cheating and the TD did exactly the right thing by giving them a loss by forfeit.

Of course there is no suspicion of cheating here. But the KGS server does not understand that. I warn participants in these events: if you log in to your bot's account during a round, using the human client, it will be assigned a loss by forfeit.

In round 3, Orego12 and AyaMC played even faster than in AyaMC's round 1 game, putting 31 stones on the board in the first 10 seconds.

In round 4, AyaMC and MyGoFriend disagreed on the status of some stones after both passing. They entered the clean-up phase, and both handled it correctly.

In round 5, gomorra16 deadlocked against MyGoFriend, and lost on time.

Zen19S vs pachi2
Move 144.

In the round 7 game between Zen19S and pachi2, a ko started with move 127. Zen19S then wasted two ko threats before starting to fight the ko. I understand that this is a consequence of "RAVE" – the program finds that the ko threat is played in the lines that win for it, so it plays it immediately, not understanding that the order of moves is important.

The ko threats resulted in a semeai between two groups at the lower edge of the board, in the position shown to the right (the ko is near the right edge). Zen19S impressed the kibitzers by playing move 144 as shown: this is the only move to win the semeai outright, with no ko. A few moves later, it impressed them less when it played at the triangled point, wasting a move to kill an already dead group.

Zen19S vs pachi2
Move 247.

Later in the game, pachi2 played move 247 as shown to the left. This appears to me to enlarge a dead group, in gote. I assumed at the time that pachi2 had decided its position was hopeless, and this move was as good as any. (This is contradicted by pachi2's claims that it had an 80% chance of winning, soon before and again soon after this move.) But Zen19S resigned less than 20 moves later. Maybe its move 247 created some aji that is too deep for me to understand.

In round 8, ManyFaces1 stopped moving in its game with pachi2. After it had been inactive for 47 minutes, I kicked it off the server in the hope of waking it up. This worked: it reappeared immediately (rather than after the five-minute delay that a kick usually produces), and started to play normally. However pachi2 won the game.
     David Fotland has explained that it is able to resume as soon as it has been kicked because it is run from a .bat file:

java -jar kgsGtp.jar tournament1.ini
goto loop

pachi2 vs Zen19S
Move 148.

After round 11 pachi2 was already sure to win the tournament: it had 11 wins from its 11 games, including two against Zen19S. In round 12 it played against Zen19S for a third time. It appeared to start well in this game too, living with a group at the top edge of the board where there had appeared to be insufficient space. But it started to make pointless-looking moves, maybe starting with move 148 as shown to the right.

Such moves, which achieve nothing but are strongly sente, are common for current MC-based programs in very poor positions. They have been attributed to a horizon-like effect: in a sufficiently poor position, moves with high variance are made, although almost certain to achieve nothing, as all variance in a lost position must be upside. But here pachi2 was making such moves, even while claiming that its chance of winning the game was over 60%. I do not understand why it did this. It continued making such moves, and eventually Zen19S won.

This game proved popular with observers, and at one point had 130 of them.

RĂ©ni Coulom's program Crazy Stone has analysed the moves of this game. Its opinions are here.

Annual points

Players receive points for the 2012 Annual KGS Bot Championship as follows:

Many Faces of Go3

Details of processor numbers, power, etc.

Aya, running on 6 cores of an i980X, at 3.3GHz.
Gomorra, running on an Infiniband cluster using 16×12cores running at 2.67 Ghz.
MC_ark, running on a Core-i7 2600K 3.40GHz*4core (8 threads)
pachi, running on 64 platforms, each x86 64 bits, 32 GB ram, using 22 cores of each (total 1408 cores), giving about 1500 playouts/s/core at the beginning of a 19x19 game.
Many Faces of Go, running 4 cores (8 threads) of an i7-2600.
MyGoFriend, running on a 20-core system: two i7s each with 6 cores and two i7s each with 4 cores, all about 3.3 mhz.
Orego, probably running on one of the five nodes of a custom Linux cluster built by PSSC Labs: the node has two AMD Six Core Dual Opteron 2427 2.2 GHz (12 cores total), 8 GB RAM, Centos Linux.
Zen, running on a mini cluster of a dual 6-core Xeon X5680@4.2 GHz 24 GB RAM, a 6-core i7 3930K@4.2 GHz 16 GB RAM, a 6-core Xeon W3680@4 GHz 12 GB RAM, and a 4-core i7 920@3.4 GHz 6 GB RAM, all connected via a GbE LAN. 4 PCs (28 cores) total.