This tournament started with 32 players (we now have 6). Round 9 just began.
5 or 6 rounds should be plenty for a 32 player tournament. There appears to be no way to see how many rounds the system thinks we should use, so I have no idea if there’s a round 10 after this one.
Here is my theory about it:
Note that the max of 8 turned out to not be true. As far as I know they are unlimited.
I’m a fan of lg(n) * (4/3) rounded up where lg is log base 2 and n is the number of players
You can also make a McMahon tournament if you want to choose the number of rounds yourself!
I don’t know which algorithm should be used, but once a tournament is started, the number of rounds is fixed, yes?
It would be nice if that information was available to players somehow.
Wow, after all these years, we still have not cracked the mysteries about how Swiss tournaments work…
Checking the backend, the number of rounds for Swiss tournaments is fixed at (N+14)/5 (truncated to integer).
That formula gives 9 for 32 players, and the API confirms that num_rounds is set to 9 for this tournament. This should be it!
IMO:
lg-based, but I don’t have an opinion on the details.Thank you for digging up the actual formula. It’s probable that whoever put that in there just didn’t understand Swiss pairings, and it kind-of almost works for small tournaments. Maybe it can get fixed someday.
Although it would be somewhat humorous to have someone pull off starting a 1000 player tournament. Should be ~10 rounds, but that formula would set it to 202 rounds.
yeah, how do you even get floor((n + 14) / 5)? Like, what’s the rationale? ceil(lg(n) * C) makes sense, as lg(n) gives your bare minimum for two player games, C (being set a bit above 1, usually) gives a few extra rounds so that it’s swiss and not just a complicated way of doing single elim, and ceil ensures that you play at least as many rounds as your parameters have deemed necessary. Everything makes sense and has a point to being there. How does one come up to with floor((n + 14) / 5), which appears to have nothing whatsoever to do with the subject at hand?
Sensei’s has more details:
An old rule to approximately decide on the number of rounds, number of players and number of validated places was invented by Mr. Model, his formula was:
R = (P + 7 x Q) /5
In which
- R is the number of rounds,
- P is the number of participants, and
- Q is the number of qualified places
I suppose that two “qualified places” means we want to be relatively sure about 1st and 2nd place. But I’ve tried to derive this weird formula from various approximations to log functions, with no luck.
Thanks @dexonsmith for finally revealing that this is the actual formula!
By the way, I’m in a Swiss tournament with 201 players. It’s almost finished 16 rounds already (about twice what @Samraku would prescribe?) yet there’s still a tie for 2nd place. I think last round 1st was tied too.
Thanks for finding the source @Feijoa! Totally explains it, since the 14 is actually spelled 7 * 2. I was kind of mystified about where this came from. Original commit had 3 (i.e., 21), and it was reduced to 2 shortly after (2014).
The phrase “invented by Mr. Model” makes me think this formula was intended as a joke. With more than about 30 players, it does indeed turn into a joke. Further down the same page is:
which is much better. (For 100 players with valid 1st, 2nd and 3rd place, the formula of “Mr Model” suggests 24 rounds, while the chess version suggests 11 rounds. For 500 players, you work it out…)
Well, whoever made that managed to troll the best English Go server into having absurd numbers of rounds for Swiss for years, so I guess I have to grudgingly respect that
I made a few simulations. The worst case scenario is when all players have the same strength. So I ran simulations of tournaments such that
For 128 players I got this graph.
There is always a unique player with 7 victories at round 7 since 128=27.
After that the graph oscillates. It seems to converge to 1 but we’d need hundreds of rounds to get a probability above 0.95, and that wouldn’t be practical.
32 players:
128 players:
1024 players:
So for n players, we need at least log2(n)+2 rounds. The results of the tournament are more accurate with more rounds but there is no need to add many more. The correct order of magnitude is log2(n), so any formula like log2(n)+constant or c x log2(n) +k where c is a constant slightly bigger than 1 and k>0 will work in practice.
The probabilities in the above graphs may seem too small, but in practice, players in a tournament don’t have the same strength, so the probability that there is no tie among the first two or three players of the tournament is much higher in practice.
How do you know this?
I am thinking that you care about achieving some density in the top Q places, say having them spread over a range 2Q of scores. If you double the number of players and add just one round, you’ll then have 2Q players within a range of at most 2Q+2 scores.
So you might need at least another Q rounds for every doubling, and in our case with Q=2, using 2 log2(n) might be a safer choice?
For your simulations, random pairing might give some more realistic, smoother curves.
I didn’t want to use random pairing since Swiss pairing is not random: players with an equal number of victories, or approximately, are paired together. This is reflected in my algorithm.
Yes it’s safer, and the order of magnitude is still log2(n), however I don’t think so many rounds are necessary. Probably something like c log2(n) +2Q for some constant 1<c<2 is good enough, maybe c=1.2. To illustrate this, I considered tournaments with 128 players.
The x-axis shows the number of rounds. The blue curve is the expected score difference between player 1 (=the winner) and player 2, and the red curve is the standard deviation. Here, log2(n)=7. Using 14 rounds is not much better than using 10 rounds. I get similar curves for the score difference between player 2 and player 3.
For tournaments with 1024 players (log2(n)=10):
Nice graphs jlt! But in my mind we want to measure something different. The goal isn’t “no ties”. If two people are actually the same strength, then it’s not bad for them to be tied. (At least in my opinion. Others may disagree.) The goal is that the 3rd strongest player actually finished 3rd (or tied for 3rd), not 8th or something silly. And if 2nd strongest is “clearly better than” 3rd strongest (plenty of room for debate on what that means!) then they should finish above, not tied.
So here is another simulation. Swiss tournament with 128 players. All players are 0 Elo, except player Alpha. I estimated the probability that after n rounds, player Alpha wins the tournament with no ties. I tested 3 situations:
It seems that 2 log2(n) is safe. In a real tournament, generally there isn’t a single player who is 400 Elo above everyone else, but also there are many weaker players.
Nice!
How does it work out with three stronger players, maybe Alpha, Beta and Gamma at 300, 200, 100? What’s the probability of getting correct places 1-3 in that scenario?
It’s nice if slightly weaker players have a chance at a win after a great performance. Not sure we want to have enough rounds that the strongest player definitely wins. Seems more like a rating system at that point, rather than a tournament.
