Estimated reading time: 9–10 minutes
“I was in fact witnessing, without knowing it, a fundamental paradigm shift that took place in those years. The emphasis was no longer on the algorithms, but on modelling — what is it for? How does one apply it?”
When mathematics went to war, the science of operational research was born.
Among the leading disciplines was this one, named simply but almost defiantly: the Science of Operational Research. Or, as it was originally called, Operational Research — a name born not in classrooms, but in the war rooms of the American and British armies.
The story of Operational Research begins during the Second World War, when the military discovered that some problems could not be solved with more soldiers or tanks, but with… mathematicians. The British were the first to create special teams — Operational Research Groups — composed of physicists, mathematicians and engineers, with a single purpose: to find optimal solutions to incredibly complex problems.
How does one protect convoys from submarines? How does one deploy radar to detect the greatest number of enemy aircraft? How does one distribute limited resources across an infinitely vast front?
One of the most famous applications was the problem of the Atlantic convoys.
The German submarines — “Dönitz’s U-boats” — hunted tirelessly the ships that carried supplies, weapons and fuel from America to Great Britain. The losses were colossal. Hundreds of ships were sinking every month. The British were on the brink of losing the war through starvation.
The British Admiralty faced an apparently simple question: which was safer — sending large convoys or small ones?
According to traditional military logic, small convoys were recommended. They were harder to detect, easier to manoeuvre, and would suffer smaller losses in the event of an attack. But the mathematicians in the Operational Research Groups carried out calculations that overturned everything the military believed. They reached a paradoxical conclusion: large convoys were far safer than small ones. Why? Because the probability of a submarine hitting a convoy depended on the convoy’s silhouette, rather than on the number of ships within it. The silhouette of a convoy of fifty ships was only slightly larger than that of a convoy of ten, yet it carried five times as many supplies.
A convoy of fifty ships presented a profile no larger than one of ten, yet transported five times as much. Moreover, the capital ships were able to protect both large and small convoys equally, since they had to patrol the same perimeter. The result? The same defensive firepower, the same probability of detection, but five times as much cargo reaching its destination. When the Royal Navy implemented this strategy — massive convoys under strong escort — losses fell dramatically. The British survived. And they won the Battle of the Atlantic. It was a simple calculation, but one that nobody had thought of before. Because nobody had looked at the problem as a system, but rather as a series of individual battles.
This is operational research: the art of transforming reality into models, models into equations, and equations into working solutions. And it saved lives.
At ASE, operational research was regarded not as something intended for wars, but for economic problems, which were every bit as complex. And in order to solve them, we studied graph theory — a mathematical instrument that seemed abstract, but described the world better than any map.
We also studied many topics related to graph theory: directed and undirected graphs, cyclic and acyclic graphs, trees, chains and networks. The use of these elements for modelling real economic systems had already begun: distribution chains, supply chains and decision-making processes.
In essence, a graph was a collection of points (nodes) connected by lines (straight or curved). Simple. But this simplicity concealed an immense power: it could be used to represent any system in which “something” moves from “somewhere” to “somewhere else.”
A network of factories and warehouses? A graph. A production process with sequential stages? A graph. A decision-making system in which every choice leads to other choices? A graph.
And once the graph was defined, it became possible to ask precise questions: What is the shortest path from A to B? What is the maximum flow? Where are the bottlenecks? Where is efficiency being lost?
Among the finest courses was mathematical programming — a name with an almost ethnic ring to it.
Abstract mathematical models came to life there: we learnt to transform a real-world economic problem into a system of equations, to write the objective function and to choose constraints — not as limitations, but as a form of respect for reality.
CROirea COrectă DIn Lemn — CROCODIL for short. An acronym, brilliantly and typically Romanian, on the borderline between ingenuity and unintentional humour, but which concealed serious work: optimisation algorithms, linear programming, complex calculations run on an IBM 360.
It was a perfect example of the ASE philosophy: mathematics must not remain in books, but must solve real-world problems — even if the problem was how to cut timber planks more efficiently for furniture.
I was in fact witnessing, without knowing it, a fundamental paradigm shift that took place in those years.
IBM had launched SSP on SYSTEM/360. SSP stood for Scientific Subroutine Package and came with 121 FORTRAN subroutines divided into three domains:
— Statistics (analysis of variance, regression, etc.)
— Matrix manipulation (inversion, linear equations)
— Other mathematical functions (integration, transforms, differential equations)
It was a library of subroutines. It still exists today, vastly expanded.
This represented the transition from computational mathematics to mathematical modelling.
The emphasis was no longer on the algorithms, but on modelling — what is it for? How does one apply it?
Today, in Python for example, it is enough to write:
from networkx.algorithms.shortest_paths.weighted import dijkstra_path
and that is that — you have the algorithm as a black box in your code and you can call it.
You do not write Dijkstra! You use it. The focus is on:
Modelling the graph correctly
Choosing the right algorithm (Dijkstra vs. A* vs. Bellman-Ford)
Interpreting the results
Less than ten years after learning these things, I solved the graph of Romania’s road communication network.
It was an enormous effort of data collection and programming.
And it was merely a subsystem of the global transport optimisation system we were building for the World Bank.
On the other hand, the spirit of the classical ASE would not let us escape its broad and bureaucratic embrace.
After theoretical accounting, we trudged through every branch of accountancy: industrial, agricultural, construction, transport, commerce. Nor did statistics spare us — from descriptive statistics all the way to inference, time series and price indexing.
It was a kind of double training: applied mathematics in economics, but also economics with a substantial layer of mathematics. And between the two stood we, the students — like acrobats on a logical tightrope, but thrilled by the novelty of it all.
Among the professors who left their mark on us were leading specialists in econometrics and economic-mathematical modelling, such as Professor Luca Tovissi, the vice-rector at the time.
He was of Hungarian origin and greatly respected by the students — not only for his academic competence, but also for an unintentional humour that made him memorable.
I did not personally witness the scene below, but the story certainly circulated among the students.
One day, he summoned a group of students who had many failed examinations. The atmosphere was tense. Tovissi looked at one of them and asked, with a slight but firm accent:
— Why do I not study, Comrade Student?
He had misspoken — he should have said “why do you not study,” but instead said “why do I not study,” placing himself in the equation.
The student, whether out of desperation or the reflexes of a cabaret performer, seized the moment immediately:
— Well, how should I know why you don’t study, Comrade Professor?
The entire room burst out laughing — led by Vice-Rector Tovissi himself, who understood the joke and laughed heartily. He was the sort of man who could take a retort and appreciate it, even when it came from a student with failed examinations.