Hi Erik,
In message
<[email protected]>, Erik van
der Werf <[email protected]> writes
Hi Nick,
A comment about your remark at the end of the report regarding the
winning chances of white: I don't think you should count all games;
uneven games (where one side is much stronger) are almost meaningless.
But maybe you didn't do that either (because I don't see how you got
to 41-39 from 20 rounds with 8 games per round), but then please tell
us where you drew the line.
I counted _all_ the games, and found 81 White wins, 79 Black wins. I
then accidentally halved the numbers when transcribing them to my report
- I have corrected this now.
I agree it would be better to exclude uneven games, and games which a
player loses by failing to join the game, or by joining it very late.
But I didn't want to have to make judgement calls.
I did a quick count for games between programs finishing in the top 5.
If I count correctly this comes to White: 13, Black: 6
Somehow I feel that these kgs tournaments are for an important part
decided by the kgs paring algorithm. It's annoying; the olympiad has
become a hardware contest and the kgs tournaments a lottery. Hardly
any good tournaments left. (Ok, maybe I'm exaggerating a bit, it's
still fun to watch :-))
I will take this as praise for the way Jukka ran the EGF Computer Go
events in Finland last month :-) They were round robins, so no
complaints about the pairing, and participants had to use the hardware
provided, or carry their own into the room, so no connections to
supercomputers.
As for the KGS events, I have considered alternatives.
I could do the draw myself. It's hard work; it takes time (slowing the
tournament down); it requires all the operators to edit their config
files before the start of each round (slowing the tournament down more);
and I would make mistakes. Ok, the KGS algorithm makes mistakes, or at
least questionable decisions, too; but no-one can accuse it of bias.
I could use a round robin format; or double, or triple, round robin, as
supported by KGS. The problem with a round robin is that the length of
the event is then determined by the number of entrants, and I don't want
a tournament to take more than eight, or less than around three, hours.
So if it's a round robin, I would need to be able to determine the time
limits and/or the multiplicity of the round robin _after_ all the
entries were in. But some people like to enter at the last minute, and
others enter in advance and then don't show up. And if I specify a
cut-off time for entries, and then remove all those who have entered and
not shown up, and only then "create" the tournament, it's going to take
me at least ten minutes to check that I have created it with all the
right settings and entered all the right programs into it. Meanwhile
all the participants are kept waiting.
Any suggestions?
Nick
--
Nick Wedd [email protected]
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
