python Archives - Kind of Lost

The Textbook Fix That Made My MILP Twice As Slow

The textbook move, when a mixed-integer program solves slowly, is to tighten the linear relaxation. Add the constraint that makes the LP bound closer to the integer optimum, give branch and bound less room to wander, watch it finish faster.

I did that to the stacking constraint in my hockey lineup optimizer last week. It got twice as slow. Same slate, same solver, same lineups out the other end — 2.20 seconds a lineup before, 4.38 after. I reverted it and left a comment telling future-me not to helpfully fix it again.

Bar chart of seconds per lineup by stacking formulation: naive 3.00, cover inequalities 2.20, two-sided counters 4.38 — Three formulations of the same constraint, same slate and solver. The textbook tightening is the slowest of the three.

Continue reading “The Textbook Fix That Made My MILP Twice As Slow”

CBC vs CP-SAT: My Lineup Optimizer Got 8x Faster

Two months ago I wrote about CBC vs HiGHS on my staff scheduler, where swapping solvers turned a model that took minutes into one that took seconds. So when my daily fantasy lineup optimizer started feeling slow, I reached for the same fix — and HiGHS came back three times slower. This is the story of CBC vs CP-SAT on that model, why my own previous result did not transfer, and the failure mode I found on the way that was worse than being slow.

▶ Try the free MLB lineup optimizer — no signup

Same Three Files, Much Harder Problem

When I finished porting the routing engine to Python, I had a 480-line file that solved vehicle routing problems and printed results to a terminal. That’s useful exactly to me, in exactly one context. The staff scheduler had already gone through the same transition — terminal script to Flask web app — and I’d figured out the pattern there. So I assumed wrapping the VRP would be roughly the same amount of work.

It wasn’t the same amount of work. But the structure was.

Vehicle routing problem with time windows solver interface

Porting 1,500 Lines of C# to Python Without Losing My Mind

The original routing model was 1,500 lines of C#. The Python port ended up around 480 lines. Some of that compression is the language — Python is more concise. Some of it is that I stripped out the proprietary cloud backend, the database calls, and the dispatch interface. What remained was the core: the model structure, the constraints, the solver parameters.

The translation itself was mostly mechanical. OR-Tools has Python bindings that mirror the C# API closely enough that you’re often just changing syntax: camelCase to snake_case, semicolons disappear, type declarations disappear. But “mostly mechanical” left room for a few things that didn’t work the first time.

Continue reading “Porting 1,500 Lines of C# to Python Without Losing My Mind”

Why Google OR-Tools and Not the Excel Solver You Already Know

The staff scheduler I wrote about a few weeks ago was a MILP — a Mixed Integer Linear Program. You define variables, constraints, and an objective function. Hand it to a solver, get an answer. Clean, relatively tractable, runs in seconds on a laptop.

The vehicle routing problem is something else entirely.