Scott Aaronson pictures a hunter-gatherer who has spent a lifetime learning to survive in a rainforest, only to find a resort opening next door, complete with heated pools and Airbnbs. The hunter-gatherer adjusts his career plans:
“alright fine, so now my new job is to run wilderness retreats for the tourists, or something.”
That is Aaronson’s analogy for the mood in mathematics after OpenAI’s release. He tells it in The Mathocalypse.
On 6 October 2026, OpenAI released a collection that now contains 719 papers in 372 groups of related results, produced by an unreleased internal model. Some concern familiar data-science tasks: matching messy text, choosing representative observations, generating comparison data and fitting models. A proof can establish that a better method is possible long before anyone has an implementation worth using.
Joe Halliwell has explored some of the release’s broader practical consequences. Here, I take a narrower data-science view: what do several of these results actually promise for familiar computational problems, and what would stand between the theorem and something we could use? The examples show how choices about accuracy, distance and randomness determine the computation, storage and data we need.
OpenAI calls each group of related results a result family. A family may include several connected results or different ways of proving one result. Of the 372 families, 205 contain one paper and 301 contain no more than two. The largest contains fourteen¹.
The release covers seventeen disciplines. Theoretical computer science has the most families, with 40, about 11% of the total. Count pages instead, and probability and statistical mechanics takes the largest share: 29 families contain 105 papers and 7,232 pages, about 21% of all pages.
The complete collection runs to 34,669 pages. The median paper is 39 pages long, and 57 exceed a hundred. Reading one PDF a day would take almost two years, assuming a 262-page paper counts as a normal Tuesday.
Some results relevant to data science sit elsewhere in the catalogue: the result about compressing feature vectors below is filed under convex and metric geometry.
Consider two entries in a customer table: Jon Smith and John Smyth. A strict text match treats them as strangers. To compare the spellings, count the fewest single-character insertions, deletions and replacements needed to turn one into the other. Here, insert an h and replace i with y: two edits. This count is edit distance, a useful ingredient in matching records whose text differs slightly.
The standard exact calculation builds a grid, with positions in one string along the rows and positions in the other along the columns. Each cell records the cheapest way to match the text up to those positions. Two strings of 10,000 characters give about 100 million cells. Double both lengths and the grid becomes four times larger.
The new edit-distance paper claims a method whose average work grows almost in proportion to the total text length, for any fixed percentage error allowance. Choose 1%: if the true distance is 100, a successful estimate is 100 or 101. The method uses randomness and promises an estimate within the allowance at least two times out of three.² Combining such a small error allowance with almost-linear growth improves on the earlier guarantees discussed in the paper.
The published recipe still uses the exact grid calculation below an enormous input-size threshold. Getting its better growth rate to pay off at lengths we can actually store is further work. Its output is a score, useful for ranking candidate matches; producing the actual list of edits would take another step.
Suppose you have thousands of support tickets and a colleague willing to read six. The colleague’s willingness is the scarce resource. You want those six tickets to represent the archive as closely as possible.
Represent each ticket as a feature vector, with similar tickets close together. Choose some actual tickets and add up every ticket’s distance to its nearest chosen example. A smaller total means better coverage under your chosen distance measure.
For six points on a line, 0, 1, 2, 8, 9 and 10, choosing representatives 0 and 10 gives a total distance of 6. Choosing 1 and 9 gives 4: each serves itself and two neighbours one unit away. Choosing k actual observations this way is called k-medoids. KMeans can put a centre between observations, which is reasonable geometry but awkward when your colleague asks to read the ticket. The broader k-median problem allows a separate list of candidate locations, such as depots serving customers.
The number of possible selections soon makes checking them all expensive. OpenAI’s k-median paper claims a tighter promise for its algorithm: if the best selection costs 100, the previous general guarantee allowed roughly 200; the new ceiling approaches 173.6³. This approximation guarantee covers every allowed dataset. Distances must obey the rule that a detour through a third point cannot be shorter than the direct journey.
The algorithm starts with an easier depot plan that permits partial openings. Six locations serve customer pairs AB, BC, AC, DE, EF and DF. Each customer is distance 1 from its two associated locations and distance 3 from the rest. We can open three depots. Opening all six halfway gives each customer half its service from each nearby location: cost 1 per customer, 6 overall. Six half-open depots fit the budget, though the building contractor may want further instructions.⁴
Whole depots cost at least 8: choosing AB, BC and DE leaves F travelling distance 3 while everyone else travels 1. Giving all six customers a nearby depot needs four openings. Each customer costs at least 1, so the partial-opening total of 6 is also as low as it can go.
Allowing partial openings can only make the best plan cheaper. Converting that optimistic plan to whole depots is called rounding. Controlling the extra cost helps prove a guarantee: a solution costing at most twice the optimistic plan also costs at most twice the best real plan.
I wanted to benchmark the complete algorithm. Following its published recipe literally, even for a looser guarantee, divides one fully open location into more than 6 × 10²⁸ tiny pieces. Touching each once at a hypothetical trillion pieces per second would take nearly two billion years.⁵ A practical implementation would need to avoid creating each piece separately.
The existing benchmark compares familiar methods on fifteen small problems with straight-line distances. An optimisation solver established their best costs within its numerical tolerances.⁶ A common shortcut swaps representatives whenever that lowers the cost, stopping when no single swap helps. A larger rearrangement might still do better.
Two versions of this swapping method each matched the best cost on fourteen of fifteen problems; their largest misses were 0.8% and 0.3%. Replacing each K-Means centre with its nearest actual observation was at worst 4.2% above the best cost.
These fairly friendly datasets leave little room to improve answer quality. Comparing OpenAI’s algorithm will need a working implementation, harder examples and timings.
Suppose you have counts of tea and coffee sales in two regions:
To study the regional pattern, you could generate comparison tables that keep both sets of totals fixed. Each region must still sell 50 drinks, with 60 teas and 40 coffees overall. Giving each region 30 teas and 20 coffees is one alternative. Moving a sale between cells forces compensating changes elsewhere.
This is a contingency table: counts split by two categories. One way to randomise it gives every table satisfying the totals an equal chance. In our tiny example, choosing North’s tea count determines all three other cells. Larger tables leave many interdependent choices.
The new sampling paper claims a method that produces exactly this uniform distribution for arbitrary compatible totals, with both the number of rows and columns free to grow. Earlier running-time guarantees described in its introduction required restrictions, such as a fixed number of rows. The new guarantee covers very uneven totals too.⁷
That provides a way to construct random data while retaining chosen features of the original. The probability model matters: giving every table equal weight differs from shuffling individual sales records, which can produce some tables in more ways than others. I would decide which comparison fits the analysis before choosing a sampler.
The paper’s running-time bound is an average over random choices, with deliberately large powers in the formula. Turning that guarantee into a useful data-generation tool still needs implementation and measurement.
Imagine fitting a model as rows arrive, without keeping the dataset. Useful information from old rows must survive in the learner’s stored state.
Suppose two unknown numbers, a and b, have sum 3 and difference 1. Together these observations give a = 2 and b = 1. Forget the sum, and both (2, 1) and (2.5, 1.5) fit the remaining information. More computation cannot recover the distinction; another observation could.
With a long stream and a fixed memory budget, the learner must choose what survives. The memory-and-precision paper studies normally distributed inputs and labels calculated from the true weights with no noise. Memory includes the bits needed to store numbers accurately.
A fixed-size summary has finitely many states, so different histories can leave identical stored information. Finer estimates require more distinctions between possible weights. Keeping extra digits can preserve those distinctions, but uses more memory.
For any summary within its stated memory budget, the paper bounds the sample budget the learner must be allowed. That lower limit grows with the number of times you halve the permitted error.8 Computation between observations is unlimited. This connects how much data to collect with how much information to retain. Even the theorem’s unusually considerate dataset, with no wrong labels at all, cannot remove that trade-off.
A feature vector is a row of numbers. To find similar observations, you may need the distances between rows more than every original coordinate.
Observations at (0, 0), (3, 4) and (6, 8) have distances 5, 5 and 10. Store them as 0, 5 and 10 on one axis, and those distances survive using one number per observation. This dimension reduction is easy because the points already lie on a line.
Existing methods preserve ordinary straight-line distances approximately in much more complicated datasets. The new paper concerns other distance rules. One adds fourth powers of coordinate differences and takes a fourth root, instead of using squares and a square root. From (0, 0), the distance to (1, 1) becomes about 1.19 rather than 1.41, while (1, 0) remains distance 1. The rule changes what counts as similar.
Using the chosen rule before and after compression, preserving distances exactly can require a number of coordinates that grows as the square of the number of observations. Allow a fixed percentage of error, and the paper’s bound eventually grows more slowly than the square root of that number.⁹ A 10% allowance means that, after multiplying every new distance by the same number, no distance shrinks and none grows by more than 10%. Nearest neighbours can still swap order: distances 100 and 101 could become 110 and 101.
The proof establishes that such a representation exists for the supplied points. An efficient construction and handling later observations remain further work.
The speed claims for three familiar operations depend on how work is counted.
The sampling result uses the accounting of a report that counts database queries and regards all the Python afterwards as a personal matter. Ten calls can still be followed by a day processing their responses.
A paper on moving one distribution onto another finds a weaker stability guarantee than researchers had conjectured: similar target distributions can require less similar movements of individual points.¹³ For a data-alignment pipeline, I would check how observations move as well as how closely the distributions match.
A proof checker is a program that checks whether an argument’s steps establish a precisely written statement from its assumptions. Lean is one such program, and journalist Kevin Hartnett tells the story of its development in The Proof in the Code.
OpenAI reports such proofs for the main results in 300 of the 719 papers, about 42%. Thepage describing the quasi-Riemann proof, for example, explicitly excludes the paper’s later applications.
The catalogue lets us make a different count: groups of related papers that link to a page describing a Lean proof. All six mathematical-logic families have such a link, compared with three of eighteen topology families. Overall it is 242 of 372 families, about 65%. Each scope page specifies which results its proof covers.
The repository history records three withdrawn papers: a sign error invalidated one construction and two papers that depended on it.
Dana Moshkovitz had spent roughly two decades working on Unique Games, a problem connected to limits on how closely algorithms can approach the best answer. Her first reaction to the new proof was confusion. Aaronson quoted her complaints about unexplained steps and confusing citations, and her description of the construction as “some alien craziness”.
She asked Astra, an AI assistant, to explain the proof interactively. By the following day, Aaronson reported that she largely understood the proof and was amazed by its new ideas.
In the comments, Jonathan Baxter suggests that a model may treat an argument scattered across ten pages as equivalent to a clearly organised version. Think of inheriting a notebook that produces the right answer, once you discover that cell 47 has to run before cell 12. Getting it to work and understanding it well enough to change it are separate jobs.
Aaronson compares the model to a junior researcher with extraordinary breadth of knowledge, the ability to connect techniques across fields and unusual persistence. Moshkovitz also emphasises that the new results build on human communities and earlier work.
I think this is a reason to study the release even before its algorithms are practical. A method that looks unwieldy in the general proof may contain an idea we can adapt to a narrower task. Understanding the reasoning is what would let us identify that idea and check whether our adaptation still works.
There is another consequence of making these results public. Hugging Face has already converted 369 of OpenAI’s mathematical challenges into reinforcement-learning environments, where models attempt formal proofs and receive feedback from a verifier. This is not conventional model distillation: no access to OpenAI’s weights or internal reasoning is required. Instead, it offers a form of capability transfer, allowing smaller open models to train against mathematical problems and verification infrastructure derived from frontier research. The current verifier is limited, however, and can reject mathematically equivalent proofs expressed differently. The interesting question is whether this training generalises beyond reproducing known results. Could a 7B-parameter model, ultimately running on commodity hardware, use what it has learned to make a genuinely new mathematical discovery? Solving a Millennium Prize Problem would be an extraordinary demonstration, although there is still an enormous distance between these training environments and that ambition.
For the k-median paper, the next useful step is to turn its partial-opening plan into a manageable implementation, identify which promises survive any simplification, and compare both answer quality and running time. Disclaimer: This was an informal, curiosity-driven project undertaken in my personal time. The views expressed here are my own and do not represent those of my employer or any affiliated organisation. The content is based on personal experience and reflection, and should not be taken as professional or academic advice.
What OpenAI’s 719 Maths Papers Mean for Data Science was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.