Eighty-third KGS Computer Go Tournament

Sunday June 3rd, 2012

These results also appear on an official KGS page.


format24-round Swiss
board size9×9
time9 minutes plus 10/30s


The first round started at 08:00 UTC.

Result table

Zen19 stv pachi AyaMC Fuego nomiB gomor ManyF Orego gnugo
W011R B114R W016R BJ2 W035 BJ13 W120R B121R B16R W115R B0172 BJ8 W110R B122R WJ23 B124R B15R W112R W19R B119R W17R B118R B11R W1444 18½318199½Winner
2stv B111R W014R B116R
WJ6 B19R W015R B019R WJ5 B112R W113R B123R B01R WJ17 B118R W020R B14R W110R B13R W12435 B18R W12R BJ21 W122R B173 17312½181¼
3pachi2 WJ2 B135 WJ13 B020R W021R BJ6 W09R B115R W119R
W14R B011R W118R B15R B07R W117R B123R B11R W114R W012R B116R B18R W124R W1102 B1222 16312160¾
4AyaMC W06R B015R W1172 BJ5 W012R B013R W023R B04R W111R B018R
B12R W021R B13R W116R B124R W17R B122R W19R B114R W110R B119R W182 B1202 15½291139½
5Fuego9 WJ8 B010R W022R BJ23 W024R W11R BJ17 W018R B120R W05R W02R B121R
B09R WJ11 B113R BJ4 W112R B116R W13R B115R B17R W114R W164 B1192 14½306½117½
6nomiBot W05R B012R W04R B010R W17R B017R W023R W03R B016R W024R W19R BJ11 W013R
B18R W015R B020R W12R B119R W122R B16R W118R W116 B11410 W12116 11½28688½
7gomorra16 B09R W019R W03R B02435 W01R B014R B07R W022R WJ4 B012R W016R W08R B115R W120R
B06R W110R B121R W1234 W15R B111R W017R W127 B1132 W018T 27568
8ManyFaces2 B07R W018R W08R B112R W016R B09R W014R B03R W015R B02R W019R B022R W16R B010R W021R B0234
W04R B113R W020R W1512 B11110 W1176 B12418 8253½46½
9Orego12 W01R B02R WJ21 B022R W08R B024R B010R W019R W07R B014R W06R B018R B05R W011R B117R B14R W013R B120R
B132 WJ9 B1122 WJ15 B016R WJ23 725632½
10gnugo3pt8 B0444 W073 B0102 W0222 B082 W0202 B064 W0192 B016 W01410 B02116 B027 W0132 B118T B0512 W01110 B0176 W02418 W032 BJ9 W0122 BJ15 W116R BJ23

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.

The numbers in the table do not add up as you might expect. This is because they include points for wins against MyGoFriend, and for byes while it was included in the tournament.

Also, I have changed the result for the round 3 game between Zen19S and pachi2 from what is shown on the KGS results page, and scored it as a jigo. Changing the "Wins" column was easy, but the "SOS" and "SoDOS" columns were difficult and may contain errors.

Before the tournament started, there were nine registered players. Adding another player would therefore avoid byes. I therefore registered MyGoFriend, which was present on KGS but had done nothing for several days. Its operators, Frank Karger 'GoCoder' and Michael Babar 'Gocrack' had last been on KGS on May 27th. MyGoFriend is particularly good at 9×9 Go, and was "Computer Go 9x9 World Champion 2010", so it would be good to have it competing.

However, in case it refused to play, I also registered and ran a build of GNU Go, using my account 'gnugo3pt8'. My intention was to remove gnugo3pt8 if MyGoFriend was able to play, otherwise to remove MyGoFriend, and to leave the numbers even.


In round 1 there were eleven players, as described above. ManyFaces2 had a bye. AyaMC played against MyGoFriend. As soon as their game started, MyGoFriend disconnected from the server, so AyaMC received a win on time. I removed MyGoFriend from the tournament.

In round 2 gomorra16 and gnugo3pt8 failed to clean up their game correctly, both leaving on the board stones which they could have captured. But the result, a win for gomorra16, was the same as if it had been cleaned up correctly.

Also in round 2 pachi2 played Zen19S. The result was jigo.

Zen19S vs pachi2
After both players passed in turn.

In round 3 pachi2 played Zen19S again. Both passed in the position shown to the right. They then disagreed about the status of the two dead stones. Play resumed, and pachi2 pachi2 passed again, as it would still win if both dead stones were counted as alive. The server treated this as the end of the clean-up phase, instead of sending a kgs-genmove_cleanup command to Zen19S. The game was therefore scored by the KGS software as a win for pachi2. This was discussed, as follows:

gghideki: No, KGS didn't give Zen to clean-up
gghideki: *give the chance
User blocked by anti-flood system in Challenge (yannou): mael
gghideki: *give Zen the chance to cleanup
testNomi: i believe zen does not implement correctly kgs-genmove_cleanup
jlg: gghideki, Zen passed after B C2. This was its mistake. It had the opportunity to capture C2 instead
maproomad: There used to be a KGS bug, it only gave one player the cahnce to clean up. But I believe
       that it has been fixed
jlg: kgs had a bug in the past in cleanup mode, but this it did not happen here.
gghideki: Not necessary. Zen reported correct dead-stone-list
testNomi: dead stone list is not used during cleanup in tournament mode
jlg: the rules are that all stones are considered alive if you pass
gghideki: Pachi didn't agree the dead-stone-list?
gghideki: No, that's cgos rules
gghideki: In the log-file, KGS accepted dead-stone-list
testNomi: but it will not use it, i believe
jlg: gghideki, you must prevent pass in cleanup mode unless all prisonners are captured
gghideki: Anyway, KGS didn't give Zen the chance to cleanup, on the log-file
gghideki: There was no cleanup mode, on the log-file
jlg: gghideki, Zen had the opportunity to capture C2. It lost this opportunity by passing.
gghideki: Not necessary
gghideki: Zen's dead-stone-list was correct
gghideki: No need to capture all dead stones on KGS
jlg: yes but the rules are not dead-stone-list. The rules are "all stones are alive after pass"
testNomi: only against humans
testNomi: in tournament mode, it is needed
maproomad: There was a dispute (Zen was right, pachi was wrong). They were both given a chance
       to resolve the dispute by marking dead stones, but Zen passed.
maproomad: So according to the rules, pachi wins
jlg: See rules in kgsGtp.xhmtl: "... they should not pass until all dead stones are removed from the board"
jlg: in description of kgs-genmove_cleanup command.
gghideki: That's sure, Noo cleanup mode in bots tournaments?
gghideki: *no
jlg: kgs sent the kgs-genmove_cleanup command in the Zen-pachi game
gghideki: Making things clean, after undo, players have to capture all dead stones, right?
testNomi: yes, exactly
jlg: you have to capture all opponent dead stones once you receive the first kgs-genmove_cleanup command
gghideki: I don't see kgs-cleanup on the log-file. I'll check again
jlg: I have the kgs-genmove_cleanup command in my log file
gghideki: I only see just a "Warning engine still claiming C2 is dead"
testNomi: this message is sent when the engine claims dead stones after entering the cleanup
gghideki: My kgs-client is 3.5.8, is this correct version?
testNomi: no, latest version is 3.5.10
jlg: oops you are right. only pachi got a kgs-genmove_cleanup command. Sorry for this
gghideki: Anyway, Zen didn't receive genmove_cleanup
jlg: zen didn't get it, you are right. So it is again the same kgs bug
testNomi: can it be a problem with the client version ?
gghideki: The KGS's bug was fixed on version 3.5.8, right?
maproomad: So KGS still has a bug :(
gghideki: I guess so
maproomad: I shall report it to wms, and hope he has time to fix it
quicksand: can you manually override the result to jigo?
gghideki: Ok, thank you for your time, Nick
jlg: gghideki, did zen receive the undo command?
maproomad: I can't affect the pairings for this tournament, but I shall recalculate the scores with that
       game counted as a tie
jlg: thanks maproomad
gghideki: yes, I see undo(s) on my log-file.
jlg: so I suggest treating undo in tournament mode as entering cleanup mode, until the kgs bug is fixed
gghideki: I'll report that to Yamato

This discussion ended with the consensus that Zen19S had acted correctly, and that because of a bug in KGS's clean-up procedure it had never been sent a kgs-genmove_cleanup command to Zen19S. I therefore stated that I would count this game as a jigo.

As an admin, I have the power to override the server and assign a result to a tournament game. But I can only do this before the start of the next round, and the consensus was only reached after lengthy discussion which continued into the next round. Moreover I can only assign wins and losses, not jigo.

Therefore the KGS software continued to believe that pachi2 had won this game. Its own results table shows it as a win for pachi, and I have modified it by hand to produce the cross-table above. KGS made its pairings for subsequent rounds according to this belief.

I will write to KGS programmer 'wms' with a description of this incident, and hope to persuade him to fix the bug.

stv vs pachi2
After both players passed in turn.

In round 6 stv played pachi2. The game ended in the position shown to the right. It is a jigo, with seki in the lower left. It was handled correctly.

In round 7 stv and gnugo3pt8 failed to clean up properly at the end of their game. This did not affect the result, stv won anyway.

nomiBot vs pachi2
The position in which pachi2 resigned.

Also in round 7, pachi2 resigned to nomiBot in the position shown to the left. It was not obvious to me, and some other observers, that Black's position is hopeless here. But now that I have studied it, I accept that pachi2 was right to resign.

After round 9, I realised that gnugo8pt3, which I was operating, was playing too fast. I started to increase its strength setting after each round, until it was at 18, which caused it to play better while still well within the time limits. Before round 15, a user told me how I could set it to use Monte-Carlo, by adding "--monte-carlo" to its configuration file. This made it play significantly better, and it beat Orego12. But pasky pointed out that I should not be making such drastic changes to it during the course of a tournament, so after this I removed the Monte-Carlo setting, and left it at its "level 18" for the rest of the tournament.

After round 10, the scores (crediting Zen19S with the round 3 jigo that it deserved), were
Zen19S 8½, stv 8, AyaMC 7½, pachi2 6½, nomiBot 6, Fuego 5, gomorra16 3½, ManyFaces2 3, Orego12 2½, gnugo3pt8 ½.

After round 14, the scores, similarly corrected, were
stv 11, Zen19S 11, AyaMC 9½, Fuego 8½, pachi2 8, nomiBot 7½, ManyFaces2 6, gomorra16 5½,Orego12 3½, gnugo3pt8 ½.

In round 18, gomorra16 fell asleep during its game with gnugo3pt8, and lost on time.

After round 18, the scores, similarly corrected, were
stv 13½, Zen19S 13, pachi2 12, AyaMC 11½, Fuego 11, nomiBot 8½, ManyFaces2 7, gomorra16 6½, Orego12 5, gnugo3pt8 3.

After round 22, the scores, similarly corrected, were
Zen19S 17, stv 15, AyaMC 14½, pachi2 14, Fuego 14, nomiBot 11½, gomorra16 8½, ManyFaces2 7, Orego12 5, gnugo3pt8 3.

Orego12 vs gnugo8pt3
move 32

In round 23, Orego12 played move 32 as shown to the right. If it had played it at f6 instead (as any human 20-kyu or stronger would have done), it would have won the game by one point. But after this move, Black had sente and used it to play at a6. It became jigo. Orego12 had thought that it would win anyway, as it believed the komi was 7½ instead of 7.

gomorra16 vs ManyFaces2
After both players passed in turn.

Also in round 23, gomorra16 and ManyFaces2 both passed, correctly, in the position shown to the left. Black should then have won, as it can kill the lower left white group. However, the players disputed the status of the group, and when play resumed Black did not attempt to kill it, so the group was treated as alive in seki with a point belonging to Black at a1, and the game was scored as a win to White by 4 points.

Annual points

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


Details of processor numbers, power, etc.

Aya, running on 6 cores of an i980X, at 3.3GHz.
Fuego, running on two Intel Xeon X5670, 24 cores at 2.93GHz.
GNU Go, running on one Intel i5-2500 CPU @ 3.30GHz,
Gomorra, running on an Infiniband cluster using 16x12cores. Cores are running at 2.67 Ghz.
Many Faces of Go, running an Amazon EC2 Cluster Compute Eight Extra Large server. Dual CPU Intel E5-2670 2.6 GHz. 16 cores, 32 threads, 60 GB shared memory.
nomitan, running on 2 Intel Xeon X5680 processors. Total of 12 cores at 3.3Ghz
Orego, runing on one node of a custom Linux cluster. The node has two AMD Six Core Dual Opteron 2427 2.2 GHz (12 cores total), 8 GB RAM, Centos Linux.
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.
Steenvreter, maybe running 46 threads each at 2.2 GHz, on a system whose use was generously provided by the Maastricht games and AI group.
Zen, running on a mini computer cluster consisting 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 GHz12 GB RAM, and a 6-core i7 980X@4 GHz 6 GB RAM PCs connected via a GbELAN. 4 PCs (30 cores) total.