This is part three of my series on rebuilding the daily fantasy lineup optimizer I started in Excel in 2012 (start here if you missed the first one). This post is about a small, clever trick I used in the spreadsheet for years to handle players who can fill more than one position — and why, when I rebuilt the tool, I deliberately threw it away.
The problem: players who qualify at several spots
In fantasy baseball, a lot of players are eligible at more than one position. Someone might qualify at both second base and shortstop; on FanDuel almost any hitter can also go in the utility slot. That flexibility is genuinely useful — a versatile player gives you more ways to fit the rest of your budget. But it makes the optimizer’s job harder, because now picking a player isn’t the whole decision. You also have to decide which slot he fills, and that choice ripples through the rest of the roster.
The Excel trick: count it, don’t assign it
Back in the spreadsheet days I had a real constraint to worry about: Excel’s Solver only handles so many variables before it gets slow or gives up. If I created a separate yes/no variable for every player-in-every-slot combination, the model ballooned. So I used a leaner trick rooted in an old operations-research idea called Fourier–Motzkin elimination. Instead of tracking which slot each player filled, I only tracked counts: for each position, I summed up everyone eligible there and required that the totals land in a legal range. The explicit “this player goes in this slot” decision got projected out of the math entirely. Fewer variables, faster solve, and Excel stayed happy.
It’s a genuinely neat piece of modeling, and I was proud of it. It also has a subtle flaw that I mostly got away with for years.
Why I retired it
Counting eligible players instead of assigning them can let through a lineup that looks legal on paper but can’t actually be filled out. Picture a handful of players who are all eligible at both first base and outfield. The counts can be satisfied — “enough first basemen, enough outfielders” — even though there’s no real way to slot them so every position has a distinct body in it. The math says yes; the contest site says no. With generous eligibility, like baseball has, those cases are rare, so the spreadsheet usually got away with it. “Usually” is a bad word to build a tool on.
When I rebuilt the optimizer in Python, two things had changed. First, the old reason for the trick was gone — a modern solver handles tens of thousands of variables without blinking, so I no longer needed to save them. Second, I wanted lineups that are provably legal every single time, not usually. So I did the straightforward thing the spreadsheet couldn’t afford: I gave every eligible player-and-slot pairing its own yes/no variable and added one honest rule — each player lands in exactly one slot, each slot gets exactly one player. It’s the textbook assignment, it can never produce an un-fillable lineup, and as a bonus it tells me precisely which slot each player occupies, which I need anyway to build the file you upload back to the contest site.
A concrete version of the bug
Here’s the failure in numbers, because it sounds abstract until you see it. Suppose your roster needs exactly one first baseman and three outfielders, and the cheapest, highest-value players the model wants are all listed as “first base / outfield.” The counting approach checks its boxes happily: at least one player eligible at first base? Yes. At least three eligible in the outfield? Yes. So it calls the lineup legal. But flip one detail and you get five “eligible” players fighting over four slots with no legal arrangement — the counts pass, yet there’s no way to put a distinct body in each spot. The site rejects it at upload, and you find out the hard way.
So what is Fourier–Motzkin, in plain terms?
You don’t need the formal version, but the intuition is worth having. Fourier–Motzkin elimination is a way to take a variable you don’t want to track and “project it out” — rewriting every rule that mentioned it into equivalent rules that don’t, so the variable disappears but its effect is preserved. In my spreadsheet, the variable I eliminated was “which exact slot does this player fill.” I never tracked it; I rewrote the roster rules as those position-by-position count totals instead. It’s the same instinct as solving two equations by substituting one into the other so a variable drops out — clean, compact, and only equivalent to the real thing under conditions fantasy rosters don’t always meet.
None of this is unique to baseball or to fantasy. Anywhere you model choices with overlapping categories — a worker who can cover several shifts, a part that fits several machines — the same temptation exists to count instead of assign, and the same trap waits if the categories overlap in a messy way. The fix is always the boring one: if the assignment actually matters, model the assignment and let the solver do the bookkeeping.
The lesson
This is the part I find satisfying after twenty years of building these things. A clever workaround is often just a monument to an old limitation. The Fourier–Motzkin trick was the right answer to “how do I fit this in Excel’s Solver in 2012.” It was the wrong answer to “how do I build a correct optimizer in 2026,” because the constraint that justified it no longer exists. Knowing when to keep a clever trick and when to drop it is most of the job. The current tool uses the boring, correct approach, and I’m happier for it.
This same “rebuild it properly” theme runs through the whole project — it’s why I’m also porting my other old models to the web one at a time. Next in this series: the part that actually wins contests, which is building not one good lineup but a smart set of them.
Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.