One of the problems with the tournament model I’ve been discussing is it’s not a very realistic model of how tournaments are normally played.

A more normal tournament design is to split the set of players into two groups, let the two groups duke it out recursively and then play the winners.

You actually can model this in the tournament setup I’ve described (you draw the hierarchy then pick a pair with a lowest common ancestor), but it’s not very natural. This seems like it needs special treatment.

It also helps that there are much fewer such tournaments. You can canonically represent every such tournament as a list of players you recursively divide down the middle, so there are at most \(O(n!)\) such tournaments. Given the bounds on the set of all tournaments this is actually a huge improvement.

I’ve pushed some initial code for such tournaments. I don’t currently know what the best way to optimise them is though. For small sets of candidates we can simply brute force try all the tournaments, but there should be a more efficient way.

One notable difference is that you can’t rig the tournaments quite so thoroughly: e.g. the strategy for boosting a candidate previously was to make everyone else fight before they reached this candidate, whileas now every candidate fights \(O(log(n))\) other candidates to be the winner. In many cases this isn’t a massive problem because you can just pair the candidate against much weaker candidates, but it still helps balance things out a bit.