Did Ada Lovelace’s Note G Have a Bug?

I originally wanted to do something much simpler: take Ada Lovelace’s Note G, the famous Bernoulli-number procedure attached to her notes on Charles Babbage’s Analytical Engine, and see whether I could squeeze it into an HP-11C programmable calculator.

That was the experiment. Could an idea written for a Victorian mechanical computer survive inside a pocket calculator from 1981?

Before I could honestly answer that, I had to answer a more basic question: does the published procedure actually work?

That question changed the whole project. What began as a calculator experiment became a computational forensics project. I had to reconstruct the procedure, build a simulator, run the published sequence, compare the result against a modern reference implementation, and then work out where the divergence began.

The simulator did run the published sequence.

It did not give the right answer.

That is where the trouble began.

Why Note G matters

Note G is often described as the first computer algorithm. That label is useful, but it can also make the story too neat. It turns Note G into a museum trophy: first algorithm, first programmer, first shiny object in the mythology of computing.

Note G matters because it treats calculation as programmable symbolic procedure. Ada Lovelace was not merely writing down a way to produce a Bernoulli number. She was describing how a machine could be instructed to carry out a sequence of symbolic operations.

The Analytical Engine was never completed as a working machine in Ada’s lifetime, but the ideas around it were astonishingly modern. It had a Store for holding values, a Mill for arithmetic, operation cards for instructions, variable cards for memory references, and number cards for constants or inputs. The vocabulary is Victorian. The hardware is mechanical. The underlying idea is familiar.

I have written before about the question of who wrote the first computer program. This investigation picks up from there, but moves from historical attribution to execution. Instead of asking who deserves the title, I wanted to know what happens when the published procedure is reconstructed and run.

Memory.

Processing.

Instructions.

State.

Control.

Note G sits in that world. It is not important because Bernoulli numbers make normal people wake up in the morning and shout with joy. They do not. Bernoulli numbers are mathematics’ recurring background characters: always turning up somewhere important, usually wearing the facial expression of someone about to ruin your afternoon.

Note G matters because it shows a symbolic procedure being prepared for mechanical execution.

That is the historical electricity.

The first complication: Note G was not a general Bernoulli engine

One of the most important discoveries in this project was also one of the easiest to miss.

Ada’s original Note G was not written as a general-purpose Bernoulli-number generator. It was designed for a specific computation: the calculation of what we would now call B8, although Ada labelled it differently in her table.

That matters because treating Note G as a modern reusable function changes the object. You are no longer looking only at the historical artefact. You are creating a modern reinterpretation inspired by that artefact.

That is not wrong, but it must be named.

So the project had to separate several things that are easy to blur together: a modern recurrence implementation, a historically-inspired Note G-style version, a transcription of the published operational sequence, corrected variants, and a future HP-11C reinterpretation.

A historical transcription is not the same as a repaired procedure. A repaired procedure is not the same as a modern recurrence formula. A modern recurrence formula is not the same as a compact calculator implementation designed to survive inside a machine with limited registers and program steps.

Without those distinctions, the investigation becomes a bowl of soup with variables floating in it.

Building the simulator

The simulator had one job: make the procedure visible.

If a value moved from the Store into the Mill, I wanted to see it. If an operation changed a variable, I wanted to see it. If the published sequence diverged from a corrected version, I wanted to know exactly where the split happened.

That is why I built a C++ simulator around the architecture of the Analytical Engine: Store, Mill, operation cards, variable references, and step-by-step execution traces. It was not meant to be a generic Bernoulli-number calculator. I needed something closer to a small ghost of the Analytical Engine.

There is another modern ingredient I should be transparent about: I used AI heavily while building the simulator.

That matters.

I did not sit there heroically wrestling C++ syntax like a man trying to strangle a crocodile with my bare hands. AI helped generate code, restructure parts of the simulator, and reduce the usual friction of implementation. The code contains plenty of pointers and moving parts, but I did not have to spend the project manually fighting memory management. That changes the labour profile of the work.

But it does not remove the intellectual responsibility.

AI could help me write code faster. It could not decide what counted as a historically faithful reconstruction. It could not tell me which compromises were acceptable. It could not inspect the meaning of a divergence and determine what the simulator had actually proved. It could generate machinery, but I still had to decide what the machinery was for, what questions it should answer, and when the answer was suspicious.

That is the strange thing about AI-assisted programming. It reduces one kind of difficulty while exposing another. You spend less time fighting syntax and more time asking whether the thing you built is telling the truth.

And under that microscope, Operation 4 started glowing red.

Operation 4: the division facing the wrong way

The suspected defect in Note G centres on Operation 4.

In the published sequence, Operation 4 divides V5 by V4 and stores the result in V11.

V5 / V4 -> V11

The proposed repair reverses the division:

V4 / V5 -> V11

Flipping a division is not a cosmetic edit. It changes the value completely. It is not the mathematical equivalent of moving a chair to the other side of the room. It is more like moving the wall and pretending the house still has the same floor plan.

In my row-level transcription of the published table, the unrepaired baseline produced a plainly wrong result. The expected value for B8 is:

-1/30

The unrepaired sequence did not produce that.

So Operation 4 looked like the obvious villain. The kind of villain who walks into the room wearing a badge that says, “Hello, I am probably the problem.”

But then something annoying happened. Fixing Operation 4 did not fully fix the procedure.

The first repair was not enough

After reversing Operation 4, the simulator produced:

1/30

That is closer. The magnitude is right. The sign is wrong.

This is the sort of result that makes you sit quietly for a moment and wonder whether the universe has taken a personal interest in wasting your afternoon.

The first repair fixed the computational pathway, but the final answer still had the wrong polarity. That meant the investigation had moved beyond a simple one-bug story.

If the corrected division gets us to the right size but the wrong sign, then another part of the sequence is mishandling the sign.

That problem appears at Line 24.

Line 24: the second wound

The second repair concerns how the sign is transferred into the final accumulation.

In the published baseline, the operation can be represented as:

V13 + V24 -> V24

The corrected version should behave as:

V24 - V13 -> V24

Operation 4 fixes the pathway. Line 24 fixes the sign. Both are needed.

That is the key point.

If you only fix Operation 4, the result looks seductively close but remains wrong. It is the mathematical equivalent of arriving on the right street and kicking down the neighbour’s door.

The three traces make the failure pattern clearer.

The published sequence is not merely a little off. The first repair corrects the main computational path, but still lands on the wrong sign. The second repair changes Line 24 and finally produces the expected value. That is why I am treating this as a two-repair problem, not a single flipped-division issue.

Here is the simplified repair map:

This is where caution matters.

I am not claiming to know who introduced the defects. I do not know whether Ada introduced them, whether Babbage’s notation contributed to the confusion, whether an engraver or transcriber made an error, whether publication introduced it, or whether later reproductions made the problem worse.

That is not what my simulator proves. What it proves is narrower and more defensible: The published operational sequence appears defective.

That may sound less dramatic, but it is the difference between doing historical analysis and running around with a flaming pitchfork shouting at dead mathematicians.

What the simulator can and cannot prove

The simulator can show that a reconstructed version of the published operational sequence produces the wrong result.

It can show that reversing Operation 4 changes the result from plainly wrong to close but still sign-wrong.

It can show that the Line 24 sign repair is needed to reach the expected value.

It can compare original, partially repaired, and repaired execution paths.

It cannot prove intent. It cannot assign blame across nearly two centuries. It cannot tell us whether the defects came from Ada, Babbage, notation, engraving, typesetting, transcription, later reproduction, or some combination of those.

That distinction matters because the lazy version of this story is very tempting: “Ada Lovelace made a mistake. Therefore the first algorithm was broken. Therefore, she was a total fraud.”

That version is dull. It is also not especially useful.

The more interesting story is this: a symbolic procedure was written for a machine that did not yet exist as a completed working engine. It used a notation system that had to express movement, memory, arithmetic, dependency, and accumulation. It tried to map mathematical recurrence into mechanical operation.

That is hard. Not mildly hard. Hard in the way that makes modern programmers stare at their own code from six months ago and wonder whether it was written by a bonobo monkey with a keyboard.

A mistake in that setting does not erase the ambition of the work. It reveals the difficulty of the work.

The procedure was living at the boundary between mathematics, notation, machinery, and publication. That is exactly the kind of place where errors breed. Not because the people involved were fools, but because the problem had many layers and very little tooling.

Modern programmers have compilers, debuggers, unit tests, version control, arbitrary precision libraries, searchable documentation, AI coding assistants, and still somehow manage to ship code that behaves like it was assembled during a power cut by a caffeinated goat.

Expecting nineteenth-century symbolic machine notation to glide through all of this without injury may be asking too much.

The B36 wall

The Note G bug was not the only surprise.

My first simulator used guarded 64-bit integer rational arithmetic. Numerators and denominators were stored using fixed-width integer types. This was exact within range, which made it useful for rational arithmetic, but the range had a hard ceiling.

Then B36 arrived.

The Bernoulli number B36 has a numerator that is too large for a signed 64-bit integer:

-26315271553053477373

A signed 64-bit integer tops out around:

9223372036854775807

Put those numbers side by side and the problem becomes obvious. You do not need a doctorate. You just need eyes and the emotional maturity to admit that one number has outgrown the box.

This exposed a wider problem: every numeric representation has a price.

A double looks like an easy escape because it has a far wider range than long long. But it changes the nature of the computation. A double can hold very large approximate values, but it cannot preserve exact rational arithmetic. It avoids the overflow dragon and walks directly into the rounding swamp wearing a nicer jacket.

For this project, exactness matters. If the whole investigation is about whether a historical procedure produces the correct rational result, then approximate rational values are not a clean solution. They may be useful for some numerical work, but they are not ideal for this kind of forensic reconstruction.

The better route is arbitrary precision integer arithmetic, such as boost::multiprecision::cpp_int, where numerator and denominator can grow as memory allows.

That does not mean cpp_int is magic. It simply moves the boundary. Instead of failing because the integer type runs out of range, the computation now depends on available memory, execution cost, and the growth of intermediate values.

This B36 wall is not the main story of the article, but it points to the deeper story underneath the whole project.

Symbolic procedures do not float above hardware forever. Eventually they collide with representation, storage, precision, time, and physical limits.

That was true for the Analytical Engine. It is true for C++. It will almost certainly be true when I return to the original HP-11C question and try to pack this repaired procedure into a calculator with very little room to breathe.

Does this diminish Ada Lovelace?

No.

If anything, it makes the story more human, more technically revealing, and more interesting.

The exact published sequence may contain defects, but the deeper conceptual achievement remains. Note G tried to express calculation as a mechanical procedure. It tried to make symbolic operations explicit enough that a machine could carry them out.

That idea survived the defects.

The history of computing is not the history of perfect machines executing perfect ideas. It is the history of ideas being forced into mechanisms that resist them.

Paper resists. Notation resists. Metal resists. Memory resists. Arithmetic representation resists. Human transcription definitely resists, sometimes with the enthusiasm of a drunk man fighting a street sign.

That is why this project became more interesting after it stopped going according to plan.

I wanted to ask whether Note G could run on an HP-11C.

Before I could do that, I had to ask whether the published Note G procedure could run correctly at all.

The answer, at least from my reconstruction, is:

Not without repair.

What survived the investigation

So what are we left with?

A published operational sequence that appears defective. A likely Operation 4 repair. A second sign repair at Line 24. A simulator that makes the divergence visible. A modern arithmetic wall at B36. And a much clearer appreciation of what Note G was actually trying to do.

The bug is not the whole story. The bug is the door. The story is what you see after walking through it.

Note G’s importance does not rest on the flawless execution of one printed table. It rests on the larger idea that calculation could be arranged as symbolic procedure and delegated to a machine. That idea was bigger than one Bernoulli number. It was bigger than one notation system. It was bigger than the unbuilt machine itself.

The defects matter because they show how difficult the leap was. They force us to stop treating historical computing as a clean parade of inevitabilities. The real story is messier. Ideas arrive before machinery is ready for them. Notation strains under new responsibilities. Engineers build toward abstractions they can barely yet test. Later readers inherit artefacts that are brilliant, fragile, and sometimes wounded.

Reproduce the investigation

The video version of this investigation walks through the reconstruction, the simulator, the Operation 4 divergence, the Line 24 repair, and the B36 wall.

The source code used for the simulator will be available in the accompanying GitHub repository. The goal is not merely to publish a claim, but to make the investigation reproducible enough that other people can inspect the machinery, run the modes, and disagree with me properly if they must.

The public bundle contains:

• the video investigation
• this article
• the simulator source code and documentation

The next question is the one I originally wanted to ask:

Can a repaired version of Note G survive inside an HP-11C?

That experiment is now much more interesting because the algorithm has been repaired enough to fight the calculator properly.

And if the calculator loses, at least it will lose to the right opponent.