Operations Research

Most of data science predicts what will happen. Operations Research (OR) answers a different, more actionable question: given limited resources and hard constraints, what should we do? How do you allocate a budget, schedule staff, route deliveries, or mix products to get the best possible outcome? OR is the discipline of turning those decisions into maths and solving them optimally.

It's the applied, decision-facing cousin of calculus & optimisation: same goal of finding a best point, but now the action space is constrained by real-world limits, and the answer is a plan you can execute. This page builds the core engine — linear programming — from formulation to solution.

The science of better decisions

OR grew out of the Second World War, where mathematicians were asked to make the best use of scarce resources — convoy routing, radar placement, supply logistics — and it became the backbone of modern logistics, scheduling, and planning. The unifying idea is simple to state: maximise (or minimise) an objective, subject to constraints. Maximise profit subject to a budget; minimise cost subject to meeting demand; minimise delivery time subject to vehicle capacity.

What makes it powerful is that an astonishing range of real problems fit that one mould. Learn to recognise the shape — an objective you want to push as far as possible, hemmed in by rules you can't break — and you can hand the problem to a solver that returns the provably best answer.

Formulating a problem

The real skill in OR isn't solving — solvers do that — it's formulation: translating a messy real situation into three precise pieces.

Decision variables — the quantities you control and are solving for (how many of product A to make, whether to open warehouse B).
Objective function — the single number you want to maximise or minimise, written in terms of the variables (total profit, total cost).
Constraints — the rules the solution must obey, also in terms of the variables (labour hours available, budget, demand to meet, non-negativity).

Get those three right and the problem is fully specified. Most of the value an OR analyst adds is here — choosing the right variables and capturing the real constraints honestly, because a beautifully solved wrong formulation is worse than useless.

Linear programming

When the objective and all the constraints are linear in the decision variables, you have a linear program (LP) — the most important and most solvable class in OR. Its standard form is compact:

\begin{aligned} \text{maximise} \quad & \mathbf{c}^{\top}\mathbf{x} \\ \text{subject to} \quad & A\mathbf{x} \le \mathbf{b} \\ & \mathbf{x} \ge \mathbf{0} \end{aligned}

x: decision variables. c: the objective weights. A and b: the constraints. The last line forbids negative quantities.

Read it plainly: choose the quantities $\mathbf{x}$ to make the weighted total $\mathbf{c}^{\top}\mathbf{x}$ as large as possible, while every constraint $A\mathbf{x} \le \mathbf{b}$ holds and nothing goes negative. A factory deciding how many of two products to build — each earning a known profit, each consuming limited labour and materials — is exactly this, and it's the example to keep in your head for the geometry next.

The geometry of LP

LP has a beautiful visual meaning. Each constraint is a straight line that cuts the plane into allowed and disallowed halves. Stack them and the points satisfying all constraints form a feasible region — a convex polygon (a polytope in higher dimensions). Every point inside is a legal plan; the objective is a direction you're pushing toward.

The key theorem makes solving tractable: the optimum always sits at a corner (vertex) of the feasible region. Intuitively, you slide the objective line as far as it will go in the improving direction, and the last point it touches before leaving the region is a corner. So instead of searching infinitely many interior points, you only ever need to check the vertices.

A 2D linear program. The constraints bound a feasible polygon; the dashed objective line slides in the improving direction until it just touches the region — at a vertex. That corner is the optimal plan.

The simplex idea

If the optimum is always at a corner, the algorithm writes itself. The simplex method — Dantzig's 1947 breakthrough, still a workhorse — starts at one vertex of the feasible region and walks along the edges to adjacent vertices, always moving to one that improves the objective, until no neighbouring corner is better. That last vertex is the global optimum.

It works because the feasible region is convex — so a corner with no better neighbour is guaranteed to be the best overall, with no risk of the local-minimum traps that haunt the non-convex problems on the machine learning side. In the worst case simplex can be slow, but in practice it's remarkably fast, and it solves LPs with thousands of variables routinely.

Duality and shadow prices

Every linear program has a hidden twin. Duality says that for any LP (the "primal"), there's a partner problem (the "dual") whose optimal value is exactly the same — and the dual's solution carries priceless management information: the shadow price of each constraint.

A shadow price answers "how much would the objective improve if I relaxed this constraint by one unit?" — how much more profit one extra hour of labour, or one more dollar of budget, would actually buy. That turns an LP from a one-off answer into a decision tool: it tells you which constraint is the real bottleneck and what it's worth to loosen it. In practice the shadow prices are often more valuable than the solution itself.

When variables must be whole

LP quietly assumes you can make 3.7 of something. Often you can't — you build 3 or 4 factories, you assign a worker to a shift or you don't, a route is used or it isn't. Forcing variables to be whole numbers gives an integer program (IP), and it's dramatically harder: you can't just round the LP answer (rounding can violate constraints or miss the true optimum), and the problem becomes NP-hard in general.

Solvers tackle it with clever search — branch and bound systematically splits the problem into cases and uses the (easy) LP relaxation as a bound to prune branches that can't beat the best solution found so far. The yes/no version, where variables are 0 or 1, captures a huge class of real decisions (assignment, scheduling, facility location), which is why integer programming is everywhere in logistics despite its cost.

Beyond linear programming

LP is the foundation, but OR is a whole toolkit. A few standout members, all framed as "optimise subject to constraints":

Network flow — model the problem as a graph and push flow through it: shortest paths, maximum flow, and minimum-cost transport. Many have especially fast specialised algorithms.
Assignment & matching — pair workers to tasks, or students to projects, at minimum cost. (The same shape as the constraint-satisfaction problems on the AI page.)
Scheduling — sequence jobs over time and machines to minimise delay or cost — classic, and classically hard.

Where it shows up in my work

From 'what is' to 'what to do'

OR is the part of the toolkit that moves from describing the world to changing it. Whenever the real question is allocation under constraints — how to deploy a limited team, a fixed budget, or scarce capacity to do the most good — that's an optimisation problem, not a prediction problem, and reaching for a model instead of an LP is a category error. The shadow-price thinking is the most useful habit it builds: in government work, knowing which constraint is the binding bottleneck, and what relaxing it is worth, is exactly the kind of insight a decision-maker can act on.

It also completes the optimisation story across these pages: calculus finds the best point on an open surface, gradient descent walks to it, and OR does it under hard constraints — three angles on the same fundamental question of "what's best?"