|time||3 hours each, absolute|
The first round started at 22:00 UTC.
In the table above,
|AyaMC vs Zen19S|
In round 1, AyaMC and Zen19S began their game as shown to the right.
Moves 1 to 7 look good. Move 8 does not look right to me – but I am
not strong enough to question it. But move 11 is surprising, and I do not
think it can be a good move.
Zen19S's operator Hideki Kato has explained to me that during this game he found a NaN in its log file, leading him to believe that one of the machines in the cluster (the 6-core Xeon W3680) was not working correctly. He removed this machine from the cluster before the next round. He believes that Zen19S was lucky to win this game.
|Zen19S vs ManyFaces2|
|Zen19S vs ManyFaces2|
|Position at move 94.|
In round 3, CrazyStone beat Zen19S, with Zen19S making some more moves that Hideki Kato thought strange. After the game, he checked the cluster again, and fell asleep before switching it on again.
In round 4, Zen19S did not appear to play its game with pachi, and lost on time.
Also in round 4, MCark obtained a totally lost position against nomiBot, but continued making purposeless moves until it lost on time. It then lost its next two games without making a move.
In round 5, CrazyStone lost its first game, to AyaMC.
In round 7, Zen19S played no strange-looking moves against nomiBot, so Hideki Kato reattached to its cluster the machine removed after round 2.
|Zen19S vs CrazyStone|
In its round 8 game with CrazyStone, Zen19S played its move 32 as shown to the left. This received some praise from the kibitzers. Zen19S eventually won the game.
In round 11, gomorra3 did not move in its game with MCark until its operator
restarted it, after two hours. Its cluster resources had expired, and it was restarted
with only 16 cluster nodes.
Also in round 11, AyaMC again beat CrazyStone.
I have two requests to make, following this event. Both are inspired by discussions with kibitzers.
Several people said it was annoying that MCark continued to play on in clearly lost
positions instead of resigning. I tend to agree. MCark has some understanding of
the game, it is not like IdiotBot. It must know when its position is hopeless, and
it ought to resign. By resigning, it would allow its opponent to switch off his
machine and save electricity, or to use it for something else, or to fix a bug. It
would also save electricity itself, and stop contributing to global warming for no
Therefore I urge MCark's programmer to make it resign in completely hopeless positions. In future tournaments, when it is completely clear that it (or any other program) has no chance of winning, I shall use my KGS admin powers to end the game and assign a result.
In view of what people have said, I have changed my mind about this.
Two users, OldGeezer 2d and RayTomes 1d, said that it was a pity that most bots do not state in their info what platform they are running on.
I agree with them. This information is of interest to kibitzers, and is available to operators. I require operators to provide me with this information, and I list it in my reports. But it is also of interest during the event, before my report has appeared.
Therefore, in future, I shall request entrants to add details of processor numbers, power, etc. to their bot's info. If they forget, I shall use my KGS admin power to add it myself.
Players receive points for the 2012 Annual KGS Bot Championship as follows: