Side Assignment Algorithm

Side assignment algorithm

The problem statement

For even rounds, the side assignment just reverses the previous odd round sides. For odd rounds,  proper side assignment takes some doing. The overall goal go al for side assignment is to increase the possible matches. For example, putting two teams from the same school on opposite sides decreases possible matches by one compared to putting them on the same side. For the same reason, teams that have already debated should be  put on the same side. In an ideally “shuffled” pool of n teams, there are

2

( 2)  possible matches; n

given team constraints, prior matches, etc., there may be considerably fewer. In fact, at small tournaments, there may be so few possible matches that a round can’t even happen. Ok, the program must pick a good pooling, one that gives a lot of possible matches and therefore a lot of flexibility. Here’s the problem: for any tournament, there are n C n  possible ways to create 2

the pools. So, for a 100-team tournament, that’s more than 10^29 possibilities (of which three or four will be used!). Even for fast computers, it’s still too big to find the optimal solution by cranking through every possibility. There needs to be a cleverer way to solve the problem. The basic algorithm

The program creates a first go, like so:

 Negs Team A Team B Team C Team D Team E Team F

Affs Team F Team E Team D 1 .99 1 .99 0 .99 0 0 1

Team C Team B .99 0 0 1 1 .99

Team A 0 1 .99

This is a matrix before a round roun d 3 pairing. Obviously, each team is blocked against itself, but I put a 0 because the algorithm doesn’t need allow it any way. The 1s are the hard blocks on teams hitting each other again on the same side: round 1 was A aff. vs. B neg., C vs. D, and E vs. F; round 2 was D vs. A, F vs. C, and B vs. E. The .99s are the “soft blocks,” where the same teams hit again but on opposite sides. If a team needs to receive a bye, the bye itself should be treated  just like a team in whole process (“BYE”), including blocks and everything.  Now, the program tries to optimize the actual pools by minimizing the total score inside the yellow boxes by following the steps listed below:

1. Starting with column 1, each column may be swapped with the next depending on which has a higher score in the first half of its rows. Team F has a higher score, so E and F are swapped:

 Negs Team A Team B Team C Team D Team E Team F

Affs Team E Team F Team D 1 .99 1 .99 0 0 .99 1 0

Team C Team B .99 0 0 1 1 .99

Team A 0 1 .99

2. Since they were swapped and the column for team F was demoted to the right, then the row for team F needs to be promoted one up (why there’s no need to code the self-block):

 Negs Team A Team B Team C Team D Team F Team E

Affs Team E Team F Team D 1 .99 1 .99 0 1 0 0 .99

Team C Team B .99 0 0 1 .99 1

Team A 0 1 .99

3. And the process repeats comparing F to the next column, where this column’s movements terminate. 4. The process continues to D, which does move: Affs Team E Team F Team C Team B Team D 1  Negs Team A .99 Team B .99 0 Team C 1 0 Team F 1 0 .99 Team E 0 .99 1

Team A Team D .99 0 0 1 1 .99

Column D actually gets g ets moved past A, so three columns right and three rows up for symmetry.

5. The program makes one last move, moving column D forward one. (This only came up once row D was moved up.)

 Negs Team A Team D Team B Team C Team F Team E

Affs Team E Team F Team C Team B .99 1 .99 0 1 0 1 0 .99 0 .99 1

Team D Team A 1 0 0 .99 1 .99

6. Now the yellow box, and therefore the pooling (E-F-C on the aff, A-D-B on the neg), is optimized. Almost all the blocked rounds have been pushed out. In other words, the impossible rounds have largely been ruled just by careful pool selections. I’m not sure if it will need to do several sweeps through the columns to make sure every possible move has been exhausted or whether once will do. 7. The program should check that this pooling actually yields two possible rounds in the yellow  box (the odd and a subsequent even round): each row should have two non-blocked opponents in yellow (true), and each column should have two non-blocked opponents in yellow (true). If either of these is false (or it’s only true using a soft block), then the program needs to flag this for the user. Using the algorithm with brackets in mind

Here’s how I think it ought to be used: the program should try to resolve the undefeated bracket alone first. At a small tournament, the undefeated bracket might not resolve on its own (have at least one empty cell in each column and row). In that case, the program should add in the downone bracket and try to resolve again. Adding another bracket should be repeated until the whole thing (of __ brackets) resolves. At the end of the whole process, pr ocess, there still needs to be a doublecheck that each team has two possible opponents, even if in different brackets. On the other hand, at most mid-sized and big tournaments, the undefeated bracket alone does resolve. The program should lock those columns in place, add on the down-one bracket, and try to resolve the down-one bracket around  the  the undefeated bracket (i.e., considering the blocks in  both but moving only the down-one teams). As it locks in a bracket, the program should consider all blocks within a bracket first, like so:

Affs A

F 2

C

2

H

1

D

1

E

0

G

0

1

B

G 1

0

E 0

1 0.99 1

0 0.99

0

2-0s and 1-1s have been locked in and will not move. The only columns that can move are the  pink ones. Deciding sides between the 0-2s, G and E, this is the correct order. When considering the overall score and the top-heaviness, the program should compare first within bracket, and then compared to the bracket above, and then two brackets above. The D-E block is more serious, because it’s one bracket off, than the C-G block. (So it would compare: against 0-2s, either pairing is just as good, against 1-1s, G is better on the aff, and so it stops there.) This should be repeated with each additional bracket, still trying to resolve the whole thing but moving only the teams in the worst bracket. It needs to do the final double-check that every team has two non-blocked opponents. My current thinking is that this process of locking the top brackets and adding and resolving one new bracket at a time will find a relatively optimal relatively optimal solution. Arbitrary selections in the u pper  bracket pools may make a difference in the end solution. To a certain extent, though, relatively optimal is good enough as long as there are enough matches available.