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.

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:

The tournament page should show the total number of rounds in the “configuration table” once the tournament starts (the frontend has this information, per the API link above; it’s just a matter of pulling it out and showing it to users).

The formula for the number of rounds doesn’t scale appropriately to different tournament sizes. Should be lg-based, but I don’t have an opinion on the details.

Agreed that it might be nice for the tournament director to have an option to manually configure it, but probably not as important as resolving the above two points.

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?

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

At each round, players are ordered by number of victories

For all k ≥1, player 2k-1 is paired with player 2k
and I estimated (by simulating 10000 tournaments) the probability that at round r, there is a unique player with the maximum number of victories.

There is always a unique player with 7 victories at round 7 since 128=2^{7}.
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.

However we don’t just want to determine a winner, we would like at least a winner with a maximum number of victories N, a second with number of victories N’<N and all other players with less than N’ victories. I got the following curves.

So for n players, we need at least log_{2}(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 log_{2}(n), so any formula like log_{2}(n)+constant or c x log_{2}(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.

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 log_{2}(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 log_{2}(n), however I don’t think so many rounds are necessary. Probably something like c log_{2}(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, log_{2}(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 (log_{2}(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 log_{2}(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.

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.