The Unreasonable Effectiveness of Operations Research

By Sanjay Saigal

On Monday, I had pointed to visibility dilemma bedeviling the profession of operations research (OR) thus:

... mentions of OR in the popular press are few and far between. Worse yet, popular media articles covering OR manage to avoid mentioning OR entirely!

On Tuesday, Steve Lohr's New York Times blog post, titled "Software Progress Beats Moore's Law," appeared. It mentioned "Martin Grotschel, a German scientist and mathematician." Over the 20-odd years that I've known Martin Grotschel, we have not discussed his primary professional affiliation. Nevertheless, even a cursory survey of his research interests will suggest that Martin is at least as much an operations researcher as he is a mathematician or an omnibus "scientist." Martin's OR expertise is entirely missing in Lohr's story. (The bias that "pure" mathematics is better, or harder, or more meaningful, than applied mathematics isn't universal, but it is pervasive. OR is application-focused. Lest I be slotted as a wannabe boiled-frog crusader, this will be my final mention of OR's branding dilemma.)

Lohr argues that improvement in the performance of software such as optimization algorithms has outpaced highly celebrated hardware speedups:

The rapid improvement in chips [...] has its own "law" -- Moore's Law, named after the Intel co-founder Gordon Moore, who in 1965 predicted that the density of transistors on integrated circuits would double every 18 months or so...

... a study of progress over a 15-year span on a benchmark production-planning task. Over that time, the speed of completing the calculations improved by a factor of 43 million. Of the total, a factor of roughly 1,000 was attributable to faster processor speeds, according to the research by Martin Grotschel, a German scientist and mathematician. Yet a factor of 43,000 was due to improvements in the efficiency of software algorithms...

But the ingenuity that computer scientists have put into algorithms have yielded performance improvements that make even the exponential gains of Moore's Law look trivial," said Edward Lazowska, a professor at the University of Washington.

My first reaction was: These don't look like Martin's results.

I have since verified my hunch via e-mail: Martin was reporting the work of his longtime associate Bob Bixby, who has advanced a more calibrated version of Lohr's argument for more than 10 years. Indeed, the performance improvement for linear optimization software has been nothing short of spectacular. Lohr's is the first recognition of this revolution that I have read in the popular press.

(To put my views in context, I did my graduate work with Bob. Years later, we also worked for the same company. However, I don't write numerical software, and I played no direct role in the results being discussed.)

Lohr mentions production planning. Such problems, technically known as mixed-integer programs, are complex variants of the steak grilling example I previously described. To get a flavor of this complexity, instead of a backyard grill, imagine an airline food-service operation that needs to turn out thousands of steak and vegetable entrees. Naturally, for such a large-scale commercial operation, lots of different grills with different capabilities are used. One grill may cook up to five steaks or 20 servings of vegetables, or any smaller combination that fits, at a time. Another may allow 12 steaks or 42 servings of vegetables, or any smaller combination. And so on. Multiple cooks staff the kitchen. Our challenge is to find a best possible sequence of grilling operations.

Recall that for our example we sequenced six operations -- three steaks with two sides per steak. For instance, our best possible sequence was [Steak1.side1, Steak2.side1, Steak1.side2, Steak3.side1, Steak2.side2, Steak3.side]. That yields -- you can work it out manually -- 11 meaningful cooking sequences from which to pick the fastest.

Now, depending on the specifics, the number of possible cooking sequences in a commercial kitchen -- the mathematician Paul Halmos once said at a similar point in his exposition, "we are now waving our hands" -- number in the billions. We cannot count our way out of combinatorial explosion. Such problems are often modeled as mixed-integer programs.

For Bob's representative test-set, the overall speedup was roughly 30 million-fold (not the 43 million in the extract above.) Think about that for a minute. A computation process that -- on 15-year-old technology -- would have taken a year to complete now takes one second. Bob's analysis showed that hardware improvements only accounted for a 1,000-fold speedup. Algorithmic improvements were responsible for the remaining 30,000-fold speedup.

How did it happen? How could algorithms improve so dramatically? The short answer: Bob and his colleagues combed through nearly 50 years of research in operations research and computer science. The mathematics was painstakingly tested; what looks clever on paper doesn't always pan out in practice. The techniques that tested best for speed and robustness (it is not uncommon for numerical codes to crash) made it into software.

Much of the research used came from U.S. universities. Contributions also arrived from academics such as Martin Groschel and his associates all over Europe, and yet others in Canada, Japan and elsewhere. Finally, commercial competition -- IBM Research was an early competitor but companies based in the UK and Scandinavia also figure in the story -- kept up the pressure.

Linear optimization codes usually work their magic hidden under many layers of enabling software -- databases, process workflows and business rules, a user interface, etc. Booking a family vacation online is a perfect example. Clicking on "Search" sets in motion a comparison of hundreds of thousands of itineraries involving air transportation, hotel reservations, car rentals, and tickets to child-friendly attractions. Optimization is critical, but it's only one step in a multi-step process. Even if the optimization module speeds up tenfold, the user experience improves only on the margin. Impressive as they are, the improvements should not be extrapolated, either to all optimization problems, or to all software. To that extent, Lohr's insight is less sensational than his title suggests.

Let me conclude with three observations:

1. Without taking anything away from computational savants like Bob, this success rests on a foundation of publicly funded research going back to the fifties and sixties. Basic research remains the key to progress in technology and business.
2. At least at the level of a sub-field, innovation is difficult to plan for or predict. In 1991, linear programming was thought to be a mature field. From 1991 through 1998, linear programming performance improved dramatically. But mixed-integer programming (its variant) remained difficult. Following a tectonic performance jump in 1998, mixed-integer programming also began to be considered practically tractable. No external pivotal event occurred in 1998; success came "overnight" due to sustained long-term effort.
3. Branding often provides limited stickiness in niche software markets. For optimization software in particular, switching costs can be low. It's easy to benchmark performance, so businesses quickly switch to whatever gives them the edge. Tall marketing claims are rarely left unchallenged. Vendor-promised benchmarks are routinely tested and validated (or thrown out). The scientific temper of operations research creates a near-ideal competitive landscape. The progress should be attributed to a combination of openness and scientific skepticism.

Sanjay Saigal is founder and CEO of Mudrika Education, Inc., with offices in Silicon Valley, CA and Delhi, India.