2

In 1956, sitting in a café in Amsterdam, Edsger Dijkstra worked out—in about twenty minutes, with no pencil—how a computer should find the shortest route between two Dutch cities. He needed a concrete problem to show off the ARMAC machine, so he picked one anybody could check on a map: the shortest way from Rotterdam to Groningen. The algorithm that came out of that afternoon is now taught to virtually every computer science student on Earth [1].

Notice the order in which he did it, because the whole idea I want to offer lives inside that order.

He formulated the demand first. Find a path of minimum total length. That sentence exists independently of any algorithm—it is a specification, not an implementation. The algorithm came second, as one way, out of many, to satisfy it. Dijkstra never confused the two. The demand was a shortest path. His procedure was one method for producing one.

And because the demand existed independently of the algorithm, the field stayed free to reinvent the algorithm entirely. Over the following sixty years, shortest-path computation was reformulated almost beyond recognition: A^* adds a heuristic; Contraction Hierarchies precompute shortcuts and answer continental queries in microseconds; hub labelling, transit-node routing, bidirectional search, landmark methods—a family whose members share remarkably little internal structure.

Not one of them was ever required to reproduce Dijkstra’s path. A new algorithm is not asked whether it visits the same intermediate cities. It is asked whether it satisfies the same specification: return a shortest path—or, in the approximate variants, one whose gap from shortest is explicitly declared. Establishing that is not trivial: summing a path’s weights tells you its cost, not its optimality. But the algorithms can carry their own evidence—distance labels and a predecessor tree form a certificate checkable in time linear in the graph. So the freedom never depended on verification being free. It depended on this: the obligation was stated without mentioning the incumbent. Dijkstra’s algorithm was one solver of a named problem. It was never the definition of a correct answer.

The stakes are silicon and joules

This is not an antiquarian point. It seems to decide what a field can afford to build. Modern accelerators pay for one shape of computation—dense, regular, reused—and a problem posed in that shape can run several times faster, at a fraction of the energy, than the same problem posed the way a sequential machine liked it. When you are free to change the formulation, that speedup is on the table. When you are not, it is not. A speech frontend we re-posed as a single matrix multiplication measured \(1.64\times\)–\(3.29\times\) speedup and up to \(3.03\times\) less energy across four accelerators—not by computing the incumbent’s answer faster, but by computing a different answer that the task could not distinguish from it [2]. Whether a field is allowed to reach for that trade is, it seems to me, exactly the question the café quietly decided.

A computation whose café conversation never happened

The dominant audio frontend in speech processing is a pipeline: a Fourier transform, a Mel filterbank, a logarithm. Decades of engineering have tuned it, vendors have accelerated it, and accelerators still inherit its assumptions. Ask the awkward question—what is the implementation-independent demand that a structurally different frontend must satisfy to replace it?—and the answer is not that audio is blind to it. Audio, of all fields, has the oracle. SincNet and LEAF replace the Fourier–Mel frontend with entirely different objects and are admitted purely on downstream task accuracy [3], [4]; the community plainly accepts a task-level criterion when it wants one.

But look at where that criterion was pointed. It was pointed at representation—at learning a task-adapted frontend—and, as far as I can see, never at the substrate. When those systems changed the formulation, they changed it in the direction that made it slower: LEAF is far more expensive to compute than a fixed Mel filterbank, and its own successors report that it fails to consistently beat one [5]. Meanwhile the part of the field that did care about speed—the ports, the vendor kernels—judged a replacement by whether it reproduced the pipeline’s output. So the demand-side oracle existed and the substrate motive existed, in the same field, and—this is the thing I keep turning over—I had not seen the two put together. Where the substrate was the reason to change, the incumbent’s output was still the test.

That is the phenomenon I want to point at. Not a field with no ruler—a field holding a ruler it never thought to use for this. The consequence is the same either way: a genuinely different frontend does not lose on the merits. On the only ruler in routine use, proximity to the incumbent’s output, it cannot be scored at all. It looks wrong because it is different, even when it serves the task equally well.

2

When a field has an implementation-independent demand, the incumbent looks like mere evidence that the demand can be met. When it lacks one—or never aims the one it has—the incumbent itself seems to become the practical oracle. I have taken to calling that transition baseline capture: the moment an incumbent stops being evidence and becomes judge. The incumbent only ever proved the demand could be satisfied. It never proved the demand had to be satisfied that way.

The lens, in four lines

The prose above wants only a little notation, and no more than this. Let \(\mathbb{O}\) be the set of possible outputs. Then \[\begin{align} &\text{a demand:} & & D \subseteq \mathbb{O};\\ &\text{P represents D:} & & \mathopen{[\mkern-1.5mu[}P\mathclose{]\mkern-1.5mu]} \subseteq D;\\ &\text{\mathit{Out} satisfies D:} & & \mathit{Out}\in D. \end{align}\] An acceptance test is a predicate \(T:\mathbb{O}\to\{0,1\}\), and the whole distinction is which set \(T\) is built from: \[\begin{align} T_{D}(\mathit{Out}) &= \mathbf{1}[\,\mathit{Out}\in D\,] \quad\text{\small(independent)}\\[2pt] T_{0}(\mathit{Out}) &= \mathbf{1}[\,\mathit{Out}\in R(\mathit{Out}_0)\,] \quad\text{\small(captured)} \end{align}\] where \(R(\mathit{Out}_0)\) is any acceptance region defined from the incumbent’s output rather than from \(D\); its extreme case \(R=\{\mathit{Out}_0\}\) is exact regression. Baseline capture is the drift \(T_D \rightsquigarrow T_0\). Writing \(A(T)=\{P : \mathopen{[\mkern-1.5mu[}P\mathclose{]\mkern-1.5mu]}\subseteq T^{-1}(1)\}\) for the formulations a test admits, \(A(T_D)\) is everything that meets the demand, while \(A(T_0)\) is only what stays within reach of the incumbent. Nothing here needs a metric, an \(\varepsilon\), or a margin. The one question a reader can carry to any paper is just: does the definition of \(T\) mention \(\mathit{Out}_0\)?

Two properties of a \(\langle\text{problem},\text{field}\rangle\) then pull apart, and should not be confused. Whether a reformulation can be judged at all looks like it turns on whether an incumbent-independent \(T_D\) exists. Whether its discovery can be automated—dropped inside a program-search loop, as FunSearch or AlphaEvolve do [6], [7]—looks like it turns additionally on whether \(T\) is cheap to evaluate. Routing has both: an independent objective and a linear-time certificate. The matrix-multiplication frontend has the first but not the second—a frozen model is an independent \(T_D\), but it costs hours to consult, which may be exactly why finding the reformulation stayed a human, experimental act. In the captured case the missing ingredient does not look primarily like a cheap evaluator. It looks like a shared, incumbent-independent demand.

Two honesties

The mechanism is old. The question I want to ask about it is simple, and it may not be mine alone. Software testing has lived with the oracle problem for decades. Weyuker described non-testable programs, whose correct output cannot be independently determined [8]. Barr and colleagues surveyed the substitutes the field reaches for—pseudo-oracles, previous versions, golden outputs—and noted that such a substitute can “migrate, over time, to become” the specification [9]. Requirements engineering calls a close cousin implementation bias: stating how instead of what [10]. I lean on all of it, gratefully—that serious people have named these pieces is what makes me think the lens is real rather than a private illusion. The question I keep wanting to ask, and have not often seen asked in these words, is what this substitution costs a computation: whether the practice quietly decides which reformulations a field is willing, or even able, to admit—and therefore how fast that field is allowed to run.

Judging by acceptability rather than numerical proximity alone is not new. Felzmann, Filho, de Oliveira and Wanner argued for evaluating approximate designs in terms of whether their outputs remain acceptable for the application, rather than treating conventional quality metrics as sufficient [11]. Theirs is prior work and I am glad to stand next to it. The distinction I find myself caring about is narrower: approximate computing ordinarily begins from an incumbent computation and asks which deviations from it remain acceptable. The cases that made me look twice need not be naturally described as degraded versions of that computation. A Mel-spaced projection is not simply an inaccurate FFT; there is no obvious parameter that continuously turns one into the other. So the question I am left with is not how much quality may I spend against the incumbent, but when is a structurally different formulation admissible at all—and the incumbent’s output, alone, does not seem able to answer that.

What buying a verifier looks like

The escape, if it is one, is not cleverness. It looks more like bookkeeping done late. When a community finally makes its acceptance condition explicit, reformulations that had been unjustifiable for years seem to become admissible almost at once. ZIP 215: independent implementations of Ed25519 had inherited their notion of a valid signature from an obsolete build of a library—bug and all—and could disagree on which signatures were valid; the fix was to write the validation rules down explicitly, which let implementations agree and, as a named reward, enabled batch validation [12]. CESM-ECT: climate simulations cannot be compared bit-for-bit across compilers, so instead of handing four hundred simulated years to a senior scientist for subjective approval, the community built a statistical test asking whether a run represents the same climate rather than the same bits [13]. In each case someone made the acceptance condition explicit, operational, and independent of the incumbent. That is all I mean by buying a verifier: not necessarily writing an objective function—CESM-ECT is a consistency test, not an objective—but making the demand answerable without pointing back at the incumbent. It has a price, and the guess I would like to test is that the price is measurable, and that paying it enlarges the space of reformulations, and thus the hardware performance, a field can reach.

Coda

Dijkstra spent twenty minutes in a café and, without meaning to, handed an entire field sixty years of freedom. Most fields never had that conversation. Whether this phenomenon deserves a name is ultimately less important than whether it exists. If it does, then making a field’s demand explicit—stating it without mentioning the incumbent—may be one of the cheapest ways we have of enlarging the space of admissible reformulations, and one of the few that can be done before a single line of the new computation is written.