A Seed row is used from Durango Bill's site (but really any combination can work other than 0, 1, 2, 3, 4, etc). Bill's seeds create better distributions for larger tournaments due to his cyclical combinatory datasets.

The seed row is expanded similar to that shown on Devenezia's site which is typical for tournament expansion.

The Pn headings identify the player slot and the number in the grid is the individual player ID. Most statistical formulas label players from 0 - n.

The grid is created by incrementing the player ID by +1. The max player ID (15 in his case) is fixed for the grid. The players IDs are recycled to 0, after the n-1 number. There will then be a 0 - n distribution for each round / row.

The grid is then incremented by +1 to make it more relatable. Often times this format is used for tournaments and satisfies the minimum partner/opponent combinations.

The tourney grid is highlighted to show the table alignment with colored bands before table optimization.

Progressive table shifting is a major part of optimization based on JDAWiseman's work.

In this case each row are progressively shifted by n mod 4 (players divided by the 4 players at each table) or 4 in this case. The first row moves entire table groups to the left. The blue table then moves to the end. The second row moves 2 Table groups to the left...so the blue and the gold table move to the end.

This progressive shuffling breaks up the #16 player from being stuck at Table 1.

However, this also causes a pattern of each player having a round where they get stuck at the same table, highlighted in light red.

Now we can then shuffle table groups ↔ within each row. This won't break the player/partner/opponent relationship we created earlier.

In this case anywhere from 1 to 3 tables are shuffled to break up the consecutive tables issue. Afterwards you'll see there is a new pattern established across the entire grid. This will not create an even distribution of players/table relationships, but no player will play at the same consecutive table. The optimizer does this across the whole schedule at once instead of by hand: for each round order it uses a beam search, keeping many partial table assignments alive and never letting a player return to the table they just left.

Finally, round / row reordering ↕ can help level the distribution and keep the extremes like a player not appearing at a table in the entire tournament. The optimizer searches the round order directly, swapping and moving rounds and keeping any order whose best table assignment balances at least as well. Typical results are about 90–95% quality at 20 players, 98% at 24–28, and 100% from 32 players up, usually within a minute.

A perfectly even distribution is not possible, because the rounds do not divide evenly by the tables (19 rounds over 5 tables is 3.8 visits each). The optimizer avoids extreme situations, and players will normally appear at each table 3–5 times, with no extremes from 24 players up. At 20 players a stray extreme or two can remain; re-running the optimizer or allowing more attempts may remove it.