Intel said the flaw would show up once in 27,000 years. IBM said once every 24 days. Both numbers were honest, both companies published their assumptions, and the $475 million went to whoever got to pick what the rate was a rate of.
On 30 October 1994, a mathematics professor in Lynchburg, Virginia, sent an email headed "Bug in the Pentium FPU" to whom it may concern. Thomas Nicely had been computing the reciprocals of twin primes, and one of them, 824,633,702,441, had been misbehaving since June. Multiply that number by its own reciprocal and you should get 1. On every Pentium he could lay hands on, a Dell, a Gateway, a Micron, an Insight and a Packard Bell, the machine returned 0.999999996274709702. No 486 he tried had the problem. He had spent four months eliminating his own code, his compiler and his chipset before he was willing to blame the processor. He had called Intel technical support on 24 October, call reference 51270, and the contact later reported that the bug had been seen on one 66 MHz system at Intel and that "no such bug had been previously reported or observed." Nicely put one condition on the information: use it freely, "as long as you give me attribution by name and employer."
Seven weeks later two other numbers were in the newspapers, and they are the reason this story is worth retelling in 2026. Intel said the flaw would appear once in nine billion divisions, which for an ordinary user meant once in 27,000 years. IBM said a spreadsheet user could meet it as often as once every 24 days, and stopped shipping Pentium machines. On 20 December Intel reversed itself, offered every owner a new chip on request, and in January booked a pretax charge of $475 million against the quarter.
The received version is that Intel's number was spin and IBM's was the truth. The documents say something more useful. Both numbers were honest. Each was derived from stated assumptions, each side published its assumptions, and IBM's own press release called Intel's description of the flaw "technically accurate." What the two companies disagreed about was not the bug. It was what the error rate was a rate of: divisions of random numbers, or divisions of the numbers a spreadsheet actually contains. That is a fight about the measurand, the quantity you intend to measure, which is a metrology question rather than an engineering one. Intel won the engineering. It lost the measurand, and the $475 million is what losing cost.
Quality managers have kept a ledger for this kind of loss since Armand Feigenbaum set it out in the Harvard Business Review in 1956 and Philip Crosby made it famous in Quality Is Free in 1979: prevention, appraisal, internal failure, external failure. The Pentium fills all four lines, and the last one is the only one anyone remembers. Walk the ledger in order and the money lands exactly where the argument was lost.
The Pentium divided with an SRT algorithm, which produces two bits of quotient per clock by looking up the leading bits of the divisor and the partial remainder in a table. Intel's own white paper on the flaw describes how the table got onto the chip: "a script was written to download the entries into a hardware PLA," and "an error was made in this script that resulted in a few lookup entries" being omitted. Five cells that should have held +2 held 0. A division that landed on one of them carried on with a wrong digit and finished with a wrong answer, usually far out in the digits, past the eighth significant digit in Nicely's case, and in the worst case in the fourth. Tim Coe, a floating-point designer at Vitesse Semiconductor, found that worst case on 14 November: 4,195,835 divided by 3,145,727 came back 1.33374 instead of 1.33382.
The prevention line of the ledger is the cost of checking that the table on the silicon matched the table on paper. It was never spent, because nobody believed the five cells could be reached. Vaughan Pratt, who took the bug apart at Stanford that winter, put the software-engineering lesson in one sentence: "the method of exercising reachable components cannot detect reachable components mistakenly believed unreachable." You cannot test the path you have decided does not exist.
Intel found the flaw itself, in the summer of 1994. Washington Technology's account that December says the engineers found it "during ongoing random testing last summer, 14 months after the chip went to market." (The Pentium shipped in March 1993, so summer 1994 is nearer 15 to 17 months; the fourteen is the reporter's, and nothing in the argument turns on it.) The appraisal that followed was serious work. The white paper Intel released on 30 November describes two independent characterizations, a Markov-chain analysis of the algorithm and an empirical run of "over 1 trillion data points," and reports that they agreed: "1 in 9 billion randomly fed divide or remainder instructions will produce inaccurate results." The fraction of the input space at risk was 1.14 times 10 to the minus 10.
Notice the word that travels with the rate every time Intel states it. "Randomly fed." In the 20 December press release, filed with the Securities and Exchange Commission as an exhibit: "once every nine billion random number pairs." In the January earnings release: "once in every nine billion random number pairs." The white paper is explicit that its whole method rests on the condition; the frequency metric holds "assuming totally random input data to the instructions." Intel then estimated that a basic spreadsheet user runs "fewer than 1000 div/day," mostly dates divided by 365, and turned nine billion divisions at a thousand a day into 27,000 years.
Do that division yourself and it does not come out. Nine billion at a thousand a day is 24,658 years; the white paper's own at-risk fraction of 1.14 times 10 to the minus 10 gives 24,033. To reach 27,000 you need about 913 divides a day, which is what "fewer than 1000" was quietly carrying. The gap is small and it is in Intel's favour, and it is the essay's own argument at one scale down: the headline consumer figure was a rounded story about a usage assumption, not a computation you could check. Intel published the assumption. It did not publish the arithmetic that turned the assumption into the number. The paper set that figure beside the other ways a PC fails: a 60 MHz Pentium system with sixteen 4-megabit DRAM parts and no error correction takes a soft memory error about once in 7 years, it said, once in 700 with ECC, and the divide flaw once in 27,000. The qualifier was never hidden. It sits in a document filed with the SEC, twice.
The trouble is that a spreadsheet does not feed a divider random numbers, and Pratt's paper shows why that matters more here than it would for most bugs. The five missing cells are reached by particular bit patterns in the divisor's mantissa, and "the distribution of the faulty pairs themselves, however, is far from random." Feed the chip uniformly random operands and you get Intel's figure; Pratt confirms it, one error in nine billion double-precision divisions. Start every calculation from the constant 1 and errors arrive "once every few minutes." Take small integers "bruised" by subtracting one millionth, the kind of value that arithmetic on rounded data produces all day, and "every 400 divisions will see a relative error of at least one in a million." Same silicon, same five cells. Nine billion, or four hundred. The denominator moved seven orders of magnitude and nothing changed except the inputs.
That is the whole dispute in one table. Intel's appraisal was a correct measurement of a quantity nobody outside Intel had agreed to care about. And its comparison with memory errors, fair as it was, was another denominator choice: it ranked the flaw against random hardware failures, the one class of failure that does not care what numbers you type.
Once it had its number, Intel treated the problem as internal. The design was corrected in a later stepping and the chip kept shipping. Washington Technology's summary of what Intel did not do: "they did not note it on their errata sheet to users, notify their technical support group or halt distribution." Nicely's email is consistent with that. The support contact he reached on 24 October could tell him the bug had been seen on one machine in-house and nothing else.
The policy that followed public disclosure was a piece of triage that only makes sense if you believe you own the denominator. Andrew Grove described it himself in the 20 December release: "Our previous policy was to talk with users to determine whether their needs required replacement of the processor." Intel would ask what you divided, decide whether your inputs were the risky kind, and replace the chip if it agreed. One user quoted in Washington Technology had his replacement approved the moment he said he worked for NASA. A spreadsheet user who insisted the bug mattered to him was, in effect, being told that his input distribution was wrong. Intel's own history page still describes the approach as "seeking to identify the people most likely to be affected by it and develop a targeted remedy."
On the ledger this line is cheap. Triage costs a phone queue. It stays cheap right up until a customer publishes a denominator of his own.
Nicely's email went to a handful of contacts. Terje Mathisen in Norway posted a test program to comp.sys.intel on 3 November. Coe posted the worst case on the 14th. On the 22nd, CNN's Moneyline reported that engineers at the Jet Propulsion Laboratory wanted to stop ordering Pentiums, and two days later, on Thanksgiving, the story was in the New York Times. Intel's annual report records the legal shape of the pressure: "During the period from November 29, 1994 through December 19, 1994, numerous civil consumer lawsuits were filed," alleging breach of warranty, deceptive advertising and consumer fraud, "and by failing to disclose it."
Then IBM changed the denominator in public. Its release of 12 December says exactly what it measured: "Common spreadsheet programs, recalculating for 15 minutes a day, could produce Pentium-related errors as often as once every 24 days." It conceded Intel's arithmetic in the same breath: "While Intel's descriptions of the flaw are technically accurate, there are many customer situations in which the risk of error may be significantly higher." G. Richard Thoman, the IBM senior vice president quoted in it, gave the reason in one line: "We believe no one should have to wonder about the integrity of data calculated on IBM PCs." IBM stopped shipping. Intel called the decision "unwarranted" and repeated that "off-the-shelf software is not affected."
Note what IBM did not do. It did not dispute nine billion. It did not find a sixth missing cell. It replaced "random number pairs" with "recalculating for 15 minutes a day" and let the chip's own behavior do the rest. That is a measurand claim, nothing more, and once a customer of IBM's size has published its own measurand, Intel's number stops being an error rate and becomes an opinion about how other people should use their computers.
On 20 December, eight days after IBM and one day after the last filing in the window the annual report describes, Intel announced an "upon-request replacement policy" and a "no-questions-asked return policy" for the life of the machine. The release says why: "The company has been criticized in recent weeks for replacing processors on the basis of need rather than on request." On 17 January it put a figure on the external-failure line: a one-time pretax charge of $475 million, $0.70 a share, to cover replacement costs, replacement material and the write-down of inventory.
Here is the part the ledger insists on and the folklore forgets. The earnings release that announced the charge is headlined "INTEL 1994 REVENUE, EARNINGS PER SHARE SET RECORDS." Revenue was $11.52 billion, up 31 percent. Earnings per share rose to $5.24 from $5.20. Net income slipped by about $7 million, from $2.295 billion to $2.288 billion. Fourth-quarter net income fell 37 percent, and the year still set records. The most famous quality charge in computing history came to 4.1 percent of one year's revenue, absorbed by a company in the middle of a boom. External failure did not wound Intel. It priced the argument.
Read Grove's paragraph once more, because it is the cleanest statement of who owns the denominator that any vendor has filed with a regulator: "We were motivated by a belief that replacement is simply unnecessary for most people. We still feel that way, but we are changing our policy because we want there to be no doubt that we stand behind this product."
He did not withdraw the estimate. He withdrew Intel's claim to be the one who applies it. The 27,000 years was correct for the operands Intel chose. The 24 days was correct for the operands IBM chose. The money went out the moment the customer's choice became the public one, and every dollar of it was spent on a program, not on a fix. The fix was five table entries, and a corrected stepping existed before the white paper was written.
Metrology has a plain word for what was missing between the two companies. The international vocabulary defines a measurand as the "quantity intended to be measured." Intel intended to measure failures per random division. IBM intended to measure failures per spreadsheet-day. Neither ever claimed to be measuring the other's quantity, so neither was wrong, and one of them paid.
We have argued the abstract version of this before, in a piece about a Stanford figure that appeared as both 12 percent and 66 percent in one document, again while tracing where the 2026 AI-failure statistics actually came from, and most closely in the safety score that is a fact about the test rig, which reaches for the same metrology vocabulary this piece does. This piece is part of Where the Number Came From, on how a published number is a fact about the way it was measured rather than about the world. What FDIV adds is the case with the receipts and the invoice attached: a denominator dispute where both parties published their assumptions, one of them was a $475 million transaction, and every document survives.
The transfer to our own decade is not an analogy. It is the same ledger with the nouns changed. A model vendor publishes an error rate. It is a rate over an evaluation set, and the vendor chose the set, in exactly the sense that Intel chose "random number pairs." Your production traffic is not the evaluation set for the same reason a spreadsheet's operands are not random: real inputs cluster, repeat, and carry the bruises of whatever produced them. The vendor's triage, when you report a failure, is Grove's old policy, a conversation to determine whether your needs require a fix. And the day you, or a customer with IBM's standing, publish the error rate over your own inputs, the vendor's number becomes Intel's number. Arithmetically correct, and publicly finished.
So the practical question is never whether a published rate is true. Assume it is. Ask what it is a rate over, and whether that population resembles yours; if the answer is not in the document, it is the word "random," somewhere, in small type. Then do what IBM did, which was less work than it sounds. IBM's study was fifteen minutes a day of recalculation on common spreadsheet programs, written up and released. Whoever publishes the denominator first gets to keep it. Intel's charge that quarter was the price of not publishing IBM's number before IBM did.
Sources:
Intel's rate was arithmetically correct and it still lost, because IBM measured the same chip over its own inputs and said so in public. The equivalent today is a record of what your agent actually did, over your traffic, that someone else can check. Chain of Consciousness keeps that record, so a rate you publish carries the population it was measured over.
pip install chain-of-consciousness npm install chain-of-consciousness
Or start without installing anything: Hosted Chain of Consciousness.