I poked at the golden ratio in SQL for fun.
An open maths problem fell over.
the authors who deserve all the credit for their original work: Benoît Cloitre, Wieb Bosma, Michel Dekking, Wolfgang Steiner, Robbert Fokkink, and Gandhar Joshi
It started with the golden ratio, years ago. I had recently learned that it was an infinite continued fraction that could be represented by a simple equation, .
How?! An infinite tower represented by an equation that even I can comprehend… this is obviously neat! I understood every piece of that expression in isolation. I know what addition does. I know what division does. I know what a square root does. Those numbers aren't magic constants, they're building blocks that a toddler can play with. How does all of that simplicity turn into an object that I personally consider to be unapproachably complex?
With no intuition, my only choice was to do what I know how to do as a programmer: treat the equation like code and swap out its parts to see how it behaved. Since SQL was my daily language at the time, my sandbox was a query.
select X = X.n
, [Circle] = [Circle].n
, [DxCircle] = X.n / NullIf(2. * Abs(X.n), 0)
, [Rectangle] = [Rectangle].n
, [Dx Rectangle] = 1. / Sqrt(4 * X.n + 1)
, [Square] = [Square].n
, [Dx Square] = 1. / NullIf(2. * Sqrt(X.n), 0)
, [Triangle] = [Triangle].n
, [Dx Triangle] = 2. / Sqrt(8 * X.n + 1)
, [Square Triangle] = [Square Triangle].n
, [Dx Square Triangle] = (1 / NullIf(2 * Sqrt(X.n), 0) + 1) * 0.5
, [√2] = ([Triangle].n - 1) / NullIf([Square].n - 1, 0)
from dbo.RangeInt(0, 1000000) X
cross apply (values((1 + Sqrt(X.n * X.n)) * 0.5)) [Circle] (n)
cross apply (values((1 + Sqrt(1 + 4 * X.n)) * 0.5)) [Rectangle] (n)
cross apply (values((1 + Sqrt(X.n)))) [Square] (n)
cross apply (values((1 + Sqrt(1 + 8 * X.n)) * 0.5)) [Triangle] (n)
cross apply (values((X.n + Sqrt(X.n)) * 0.5)) [Square Triangle] (n)
Every one of those cross apply lines is the golden ratio's formula with a piece swapped out. Keep the skeleton (<x> + √<y>) / <z>, change a variable, watch what happens. Eventually I settled on the form (1 + √<y>) / 2 because it had the most approachable results. Two things jumped out at me, and I could not explain either of them.
First: the floors of the outputs all counted. Each variant, fed the right inputs, enumerated the positive integers — not approximately, every one of them hit every positive integer. Different formulas, same infinite result. That felt marvelous but also really weird. How was I supposed to tell these functions apart when the only tool I had effectively insisted they were all the same?
Second: when I looked at which inputs made each formula land exactly on an integer, I recognized them. They were the figurate numbers: triangular numbers, square numbers, etc. The names in the query (Triangle, Square, Rectangle) are literal because each variant is the formula that inverts its shape, reversing the stacking of dots into triangles or squares.
I felt like there was something there, but I just didn't know enough to say what it was or explore much further on my own. So the query sat in a public gist, saved under the name Nonsense.sql because that's what I believed this exploration to be…
Modern LLMs enter the chat
Recently, I was digging through my old gists to hopefully find inspiration for the application I've been building, and I ran into Nonsense.sql again. Reading it back, I thought the figurate numbers might end up being useful to me. I can't tell you how… that's still just a hunch, but I really needed a break from correctness and performance validation for a bit.
So I handed the query to Gemini (3.1 Pro) and asked it to make something useful out of my code. I explained the observations I'd made back then about the counting, the figurate inputs, and the fact that every variant seemed to give the same answer. Then I pushed for what I actually wanted: the general formula underneath them all. We went back and forth like that, developing and generalizing until I felt like the limit had been reached.
Later, I handed the pile of formulas to Claude (Fable 5/Opus 4.8) for implementation and asked the question I'd never had anyone to ask before: “What is the object that represents this?” The first answers were too specific. Every time it handed me something tied to one of my examples I pushed it to generalize further by asking “What's underneath that?” This went on for a while and what came out the other side was a small pile of code in my application's math library:
LayerSequence— a layered index space whose layer boundaries are exactly the generalized figurate numbers, answering “which layer is index n in?” by inverting the quadratic in pure integer arithmetic. MyTriangleandSquarecolumns, made rigorous.ModularTransform— exact 2×2 integer matrices of determinant one, the modular group, which turned out to be the single object underneath everything else.MetallicQuasicrystalandQuadraticQuasicrystal— the golden ratio generalized to the whole metallic family, , each one generating an aperiodic tiling by inflation. The golden ratio is just .
Those descriptions and names obviously aren't mine because I don't really understand any of the maths involved. I can read code though, and now I had a toolkit I could actually play with. It did everything I'd been asking for:
- It never debases itself by touching a float. It's integers the whole way through, square roots included, so I get deterministic results for every query.
- Nothing in it is a special case. There isn't a line or conditional anywhere that says “and here are the triangular numbers” or “and here's the golden ratio”; they just fall out of the machinery. The figurate numbers are where the layers land, the golden ratio is , and there are all kinds of other families in there that I can't even name.
- No loops, constant time execution everywhere. Nothing in it ever counts up to an answer; asking which layer an index lives in just inverts the function. Membership works the same way, and so does stepping forwards and backwards.
So how do these toys connect back to my query? The robots tell me it comes down to three naive questions:
First: what is this the inverse of? I wanted the inverse: hand a dot its layer back instead of building up to it. The
Trianglecolumn was doing exactly that all along.(1 + Sqrt(1 + 8 * X.n)) * 0.5is the skeleton(1 + √<y>) / 2withy = 1 + 8 * n: stacking dots into triangles is a counting formula, and this is that formula run backwards — the square root un-stacks the dots, and the leading 1 numbers the layer itself instead of the step below it. That's why the floors counted, and why the exact hits were the figurate numbers: they're the layer boundaries. Turn the first layer, the growth, and the center dots into knobs and you've builtLayerSequence.Second: what if I feed the formula to itself? The metallic family is the full skeleton,
(<x> + √<y>) / <z>withx = k,y = k² + 4,z = 2; plug ink = 1and out comes the golden ratio that started this whole essay. Feed any of them their own answer, forever, and nothing changes — that loop is the determinant toy from a couple widgets up:twisting and stretching while its determinant never moves (I can't read matrix notation, but the toy already showed you that part). Iterate and the modular group shows up on its own. That's
ModularTransform.Third: what does it look like? stretches space by the metallic mean, so cutting tiles by that rule, the inflation tilings fall out — Penrose at and Ammann–Beenker at . That's the
MetallicQuasicrystalfamily.
Invert, iterate, draw. Here's the whole path on a single page.
The Jacobian conjecture is disproven*!
On July 19th, 2026, Levent Alpöge posted on Twitter. The post read “hello there the jacobian conjecture is false thanx” and contained an equation. Using Fable, he had found a counterexample to the Jacobian conjecture: an 87-year-old problem, resolved in a mere tweet, solved by a robot parrot. The same conjecture once derailed the early career of Yitang Zhang. He wrote his doctoral thesis on it, never published it, and spent years outside academia afterwards; the kind of blow that keeps people away from hard problems forever. He kept going anyways, and decades later he became famous for prime gaps.
I relay that latter story because everyone in it was wrong. Zhang's thesis didn't survive, and the conjecture itself — the thing experts spent eighty-seven years trying to prove — turned out to be false. Even the greats miss, and I find that a bit freeing: not everyone can prove a great theorem, but a great theorem can come from anywhere… even from a man who felt forced to perform sums while working in a sandwich shop.
Inspired to goof off, equipped with some new toys, and just having learned about the /goal directive, I asked ChatGPT (GPT-5.6) to review the toolkit Claude had implemented. It found some bugs, we fixed them, and then I sent this exact prompt:
/goal Use our new toolkit to explore the state of the art. Find relevant open math problems and do not stop until you have successfully used the kit to solve at least one open problem.
A hair over sixteen minutes later, it claimed it had solved one. What?! Nonsense! Poppycock even!
So, I reviewed the logs to see what it had actually done and, indeed, it went hunting through open problems, looking for one that was shaped like the toolkit, and settled on a conjecture that had been left in the closing paragraph of a 2018 paper; restated last year with a note that the general case was still open. Then it applied the tools and a solution emerged.
I was out of Fable credits, so I settled for Opus 4.8 and asked it to check. It doubted the claim, as it should have, but it thought the result was correct. Gemini agreed. Then I had ChatGPT prove it in Lean, and it claimed it had.
That's when I started taking it seriously, because this is just not how it usually goes. If you've ever had a model hand you a fantastical result, you know the drill: you send it to another model and watch it get torn to pieces; it doesn't get turned into a Lean proof. Time to email Daniel Lemire who knows I'm ignorant AF and is kind enough to humor me anyways. He wrote back:
I am optimistic that this is correct. You should do a write up (at least a gist).
Here we are now.
The Bosma–Dekking–Steiner conjecture is proven**?
In 2018, Bosma, Dekking, and Steiner published a paper titled A Remarkable Integer Sequence Related to π and √2, and in its last paragraph they left a conjecture. In 2025, Fokkink and Joshi restated it as Conjecture 20 of their paper on Cloitre's hiccup sequences, proved a special case, and noted that the general proof was still missing. The mathematics that follows isn't mine, so what you're getting is my retelling of the models' account, the same way I'd explain someone else's code after stepping through it.
Fix an integer and let , the -th metallic mean; the golden ratio is the case . Now consider the sequence defined by the recurrence
an infinite continued-fraction-like tower, each term leaning on the next one forever. The conjecture says that the floor of this infinitely nested object is exactly the floor of a straight line:
for every and . The proof runs through exactly the objects Claude had built, only read forwards this time. Getting the left-hand side, , is move 1 all over again: you run a quadratic backwards, exactly like the Triangle column did, which is precisely what MetallicPolynomialContinuedFraction does when it hands back the floor of the whole tower in constant time, never once building the tail or rounding a metallic mean. Underneath the -th metallic mean sits one tiny integer matrix, the same from move two,
with two numbers baked into it: a big root and a small one. The big root is itself, the slope of the straight line. The small one, its conjugate, is what makes the whole thing work: it converts the question “can an integer sneak into the gap between the line and the tower?” into a question about size. Any integer that tried to sneak in would hand you a quadratic norm: a positive whole number provably congruent to , and therefore provably too big to fit in the gap. Nothing fits, so nobody sneaks in, and the floors agree everywhere.
Conclusion
Is it true? Here is exactly what I can and can't tell you.
- The proof was formalized in Lean 4 against mathlib; the top theorem is
bds_conjecture, and you can rebuild and re-check it yourself with two commands. - The final theorem has no
sorry, noadmit, and no axioms of its own (the authorities tell me that this is a good thing). - A separate verifier re-checks the whole construction in exact rational arithmetic, no floating point anywhere —
dotnet runreplays it fork = 1..32,n = 1..512, then again at 256-bitkand 320-bitn.
My understanding, as an outsider, is that the kernel has already checked every step of the proof; that is its entire job, and it doesn't care that a robot parrot wrote the thing. What still needs human eyes is the statement itself: does the theorem in the Lean file actually say what Conjecture 20 says on paper? I can't answer that one.
This kind of recreation used to be borderline impossible; not because the maths was out of reach, but because the company was. How many others in the world could possibly care about some random sequences that fell out of my contrived SQL query? Collaborators are a mere prompt away now: completely different AI models, happy to care about anything at any hour, no matter how niche.
You probably have a Nonsense.sql of your own: a shelved question you stopped taking seriously because nobody around you could possibly have cared. Go pick it up and play around a bit. Use your imagination, borrow from the bots whenever you find your own wanting, and if you discover something interesting then share it with someone, because that is how this whole thing worked: strangers helping strangers, some human, some not, some no longer with us, each one leaving something behind for those who come after.
*Disproven in three dimensions and above, the two-dimensional case is still open.
**Proven, pending human verification.
Sources:
- Benoît Cloitre – the inspiring OEIS sequence
- Wieb Bosma, Michel Dekking, and Wolfgang Steiner – A Remarkable Integer Sequence Related to π and √2
- Robbert Fokkink and Gandhar Joshi – On Cloitre's hiccup sequences
- Benoît Cloitre – The Golden Sieve
- ByteTerrace/Nonsense – Source Code