The Mathematics of Swim Relay Lineup Optimization

1. Introduction to Relay Optimization Swim relay planning is a classical assignment problem in operational research. For a single medley relay event, a coach must select four swimmers from a roster and assign each to one of four strokes: Backstroke, Breaststroke, Butterfly, and Freestyle. The objective is simple: minimize the total relay split duration.

While this sounds straightforward, the practical realities of team management introduce significant complexity. In many recreational or masters swim clubs, coaches attempt to solve this problem manually, relying on intuition or simple spreadsheets. However, human decision-making is prone to cognitive biases and limits. A coach might instinctively place their fastest swimmer on their favorite stroke, failing to realize that a globally optimal solution might require that swimmer to swim a different stroke where the team's alternative options are far weaker. This is known as the "opportunity cost" of swimmer allocation.

By formalizing the relay selection as a mathematical optimization problem, we can find the mathematically proven fastest possible lineup. This approach removes emotional bias, saves coaches hours of manual calculation, and ensures that every swimmer is placed in the position where they can contribute the most to the team's success.

2. Mathematical Formulation To model this problem, let $I$ represent the set of active swimmers, and $J$ represent the set of relay slots (where $J = \{1: \text{Back}, 2: \text{Breast}, 3: \text{Fly}, 4: \text{Free}\}$). We define a binary decision variable $x_{ij}$ where $x_{ij} = 1$ if swimmer $i$ is assigned to stroke $j$, and $0$ otherwise.

Let $t_{ij}$ represent the seed time of swimmer $i$ in stroke $j$. The objective function is:

$$\min \sum_{i \in I} \sum_{j \in J} t_{ij} x_{ij}$$

Subject to the following constraints:

1. **Stroke Coverage:** Every stroke slot must be filled by exactly one swimmer: $$\sum_{i \in I} x_{ij} = 1 \quad \forall j \in J$$ 2. **Workload Caps:** No swimmer can swim more than one stroke in a single relay team: $$\sum_{j \in J} x_{ij} \leq 1 \quad \forall i \in I$$ 3. **Binary Assignment:** $$x_{ij} \in \{0, 1\} \quad \forall i \in I, j \in J$$

This formulation is a classic Linear Program (LP) with integer constraints, specifically a Binary Integer Program (BIP). Because the constraint matrix is totally unimodular, solving the relaxed linear program where $x_{ij} \in [0, 1]$ is guaranteed to yield integer solutions, allowing us to use extremely fast continuous optimization algorithms if needed.

In mixed gender relays, additional constraints are introduced to ensure that the team consists of exactly two male and two female swimmers. Let $I_M \subset I$ be the set of male swimmers and $I_F \subset I$ be the set of female swimmers. The gender balance constraints are:

$$\sum_{i \in I_M} \sum_{j \in J} x_{ij} = 2 \quad \text{and} \quad \sum_{i \in I_F} \sum_{j \in J} x_{ij} = 2$$

These gender constraints further restrict the feasible solution space, making manual optimization even more challenging, but they are easily handled by modern linear solvers.

3. Solving the 24 Permutations For a single relay team, the problem size is small. Choosing 4 swimmers from a roster of $N$ swimmers yields $\binom{N}{4}$ swimmer combinations. For each combination, there are $4! = 24$ stroke assignments. Thus, the optimizer evaluates:

$$24 \times \frac{N!}{4!(N-4)!}$$

permutations. A roster of 16 active swimmers results in $1,820$ combinations, requiring $43,680$ checks. Modern web browsers solve this in under 5 milliseconds.

However, as the roster size grows, the number of permutations increases dramatically. For a roster of 32 swimmers, the number of combinations is $\binom{32}{4} = 35,960$, which translates to $863,040$ permutations. While still computationally trivial for a desktop computer, running this search in a single-threaded browser environment requires careful optimization to prevent frame drops or "unresponsive script" warnings.

To optimize the search, we can apply branch-and-bound techniques. For instance, if the current best team time is $T^*$, and during our evaluation of a permutation the partial sum of the first three legs already exceeds $T^*$, we can prune the search tree and immediately skip the remaining assignments. This simple heuristic reduces the actual number of evaluated permutations by over 70%, ensuring smooth performance even on low-end mobile devices.

4. Multi-Event Scaling & Sequential Drafts In multi-event planning (e.g. optimizing 5 relays simultaneously), the optimization complexity scales exponentially. If we have $E$ events and a roster of $N$ swimmers, the global assignment problem requires assigning swimmers across multiple events while respecting individual workload limits. A swimmer might be limited to a maximum of 3 relays total.

To solve this globally, we would need to model the problem as a multi-commodity network flow or a large-scale mixed-integer program. The number of decision variables becomes $x_{ije}$ where $e \in E$, and the constraints couple all events together. Solving this global model is NP-hard, and finding the exact global optimum can take minutes or hours for large rosters, which is unacceptable for an interactive web application.

To ensure computational viability in browser runtimes, our engine supports **Sequential Drafting**. This algorithm prioritizes building the fastest valid Team A first, locks those swimmers, and then solves the assignment problem for Team B using the remaining roster. This maintains high quality lineups without crashing browser threads.

Coaches can customize the priority order of the events. For example, if a coach wants to maximize the chances of winning the 200 Medley Relay, they can rank it first. The algorithm will draft the absolute fastest combination for that relay, and then optimize the remaining events with the leftover swimmers. This greedy event-by-event approach runs in $O(E \cdot N^4)$ time, which completes in a fraction of a second.

5. Practical Implementation Considerations When implementing the optimization engine in TypeScript, several practical constraints must be addressed. One major challenge is handling missing or incomplete data. In real-world rosters, many swimmers will not have recorded times for every stroke. A freestyle specialist might have a 50 Free time of 22.5 seconds, but a null or zero value for the 50 Breaststroke.

If the solver encounters a null or zero time, it must not treat it as a swim time of 0 seconds, as the optimizer would see this as an incredibly fast swim and assign the swimmer to that stroke. Instead, the solver can either: 1. Exclude the decision variable $x_{ij}$ from the LP formulation entirely, representing an infeasible assignment. 2. Substitute a massive penalty time (e.g., 99:99.99) for the missing stroke, ensuring the optimizer avoids it.

Additionally, the user interface must allow coaches to "lock" specific swimmers into certain slots. If a coach knows that Swimmer A must swim Backstroke in the Medley relay (perhaps because they are the only swimmer comfortable with in-water starts), the system must pre-assign $x_{\text{A, Back}} = 1$ and remove Swimmer A and the Backstroke slot from the optimization pool. This reduces the search space and gives coaches the perfect blend of automated optimization and manual control.