A mathematically faster Fourier transform need not run faster on a computer. That distinction is at the center of Ben Recht’s critique of an AI-generated result in OpenAI’s public mathematics collection.
In his October 12, 2026 post, “Faster Fourier Transforms”, Recht argues that the claimed improvement depends on enormous hidden constants and a computational model that treats exact operations on complex numbers as single steps. In his assessment, those conditions make the proposed algorithm impractical on real hardware.
That is a challenge to the result’s practical significance, not an independently established disproof. Recht also discloses an important limitation of his analysis: he used ChatGPT to extract details from the manuscript rather than reading it directly.
The useful question is therefore narrower than whether AI has “solved” faster Fourier transforms. What does OpenAI’s result claim to improve, what does its cost model leave out, and what evidence would turn a theoretical advance into a usable algorithm?
OpenAI Released a Mathematical Collection, Not a Speed Test
OpenAI’s public mathematics repository describes a collection of mathematical manuscripts and supporting proof artifacts produced by an unreleased internal model. Its catalogue contains 719 manuscripts organized into 372 families, with related papers grouped around principal results, companion arguments, consequences, or alternative proofs.
The disputed manuscript is titled “An Explicit Power-Saving for the Exact Discrete Fourier Transform”. The word exact matters: the debate concerns an arithmetic-complexity result, not a published timing comparison showing a replacement FFT outperforming existing software.
The discrete Fourier transform, or DFT, converts a sequence of samples into its frequency components. Computing those outputs directly takes quadratic arithmetic work: roughly proportional to the square of the number of samples. Standard fast Fourier transform algorithms reduce that growth to approximately (n\log n), where (n) is the input length.
According to Recht’s account, OpenAI’s claimed improvement makes the logarithmic contribution slightly smaller asymptotically. That could be meaningful as a statement about an abstract computational model. It does not, by itself, tell a developer whether a transform will finish sooner, consume less memory, or produce reliable numerical output.
OpenAI’s own repository cautions against treating the collection as uniformly verified. It says the results are at different stages of verification, that not all have accompanying Lean formalizations, and that some unformalized results could have issues. That warning does not establish a problem with this particular manuscript, but it sets the appropriate level of confidence for the release.
Hidden Constants Can Swallow an Asymptotic Improvement
Recht’s first objection concerns what big-O notation hides.
When an algorithm has a complexity bound of (O(f(n))), the statement says that its cost is bounded by a constant multiple of (f(n)) once the input becomes sufficiently large. It ordinarily suppresses both the multiplicative constant and the threshold at which the guarantee applies.
Those omissions are useful when studying how algorithms scale. They become dangerous when an asymptotic result is presented as a practical speedup without examining the suppressed quantities.
For illustration, consider an algorithm whose cost grows as a trillion times (n). It is linear, so its growth rate is eventually better than (n\log n). Yet an algorithm costing approximately (n\log n) could remain cheaper throughout every input size a user can realistically process. This is an illustrative comparison, not a measurement of OpenAI’s algorithm.
Recht places OpenAI’s construction in the category sometimes called a galactic algorithm: an algorithm with attractive asymptotic behavior but constants or thresholds so large that its advantage is inaccessible in practice. In his analysis, he estimates a hidden constant around (10^{100}). That number should be understood as part of his critique, not an independently verified performance measurement.
There is another distinction worth preserving. A complexity upper bound is a guarantee about cost, not necessarily a precise description of an implementation’s runtime. Comparing two upper bounds alone does not establish exactly how much faster or slower their implementations would be.
Nevertheless, an enormous constant prevents the improved asymptotic expression from serving as convincing evidence of practical acceleration. To make that case, researchers would need sufficiently explicit costs, feasible input sizes, and eventually an implementation tested against a relevant baseline.
The theorem could still have theoretical value. Establishing that a growth rate is possible can motivate better constructions or clarify what a computational model permits. But that value should be described separately from the claim that users now have a faster FFT.
Exact Complex Arithmetic Changes What an “Operation” Costs
Recht’s second objection goes beyond constants. It asks whether the operations being counted resemble operations a physical computer can perform.
His account says the construction uses exact complex arithmetic, allowing multiplication of complex numbers to count as a single operation even when their representation would be costly. He further argues that intermediate numbers become so large that storing and manipulating them would impose prohibitive requirements.
An arithmetic-operation count abstracts away those representation costs. That abstraction can be appropriate for a mathematical question, but it does not automatically transfer to a machine-level runtime claim.
Actual numerical software must represent values using finite resources. Ordinary floating-point calculations round their results. Higher-precision arithmetic can reduce rounding error, but it requires additional storage and computation; it does not make arbitrary exact arithmetic free.
Consequently, reducing the number of abstract multiplications may fail to reduce the amount of work performed by a computer. An algorithm could use fewer arithmetic steps while making each step much more expensive.
Nor does an exact-arithmetic proof automatically establish that a floating-point implementation will remain accurate. A practical implementation needs an analysis of precision requirements and numerical behavior, alongside its operation count.
Recht’s conclusion is that OpenAI’s result does not solve the practical problem he associates with finding a faster FFT. That conclusion depends on his reading of the construction and its assumptions. The defensible broader lesson is conditional: an improvement proved in an exact-arithmetic model needs additional evidence before it can be advertised as a real-computer speedup.
Recht’s Critique Does Not Settle the Theorem
The critique is technically specific, but its method limits what readers should take from it.
Recht explicitly says he did not read the manuscript directly. Instead, he describes using ChatGPT to retrieve salient details. That disclosure matters particularly here: an argument about AI-generated mathematics should not silently treat another model’s extraction of the paper as independent verification of its contents.
His post identifies concrete points for further checking: the hidden constants, the input sizes required for an advantage, the treatment of complex arithmetic, and the size of intermediate values. These are more useful than a general dismissal of AI-produced research because they identify where practical claims could fail.
Still, the cited material does not independently adjudicate the manuscript’s proof. The possibility that its theorem is correct under its stated assumptions remains separate from whether its algorithm is useful on available computers.
Several outcomes are compatible with the dispute. The proof might establish a genuine theoretical improvement with no practical benefit. A later construction might improve its costs. Closer examination might reveal an error or show that some part of Recht’s interpretation needs correction. The available evidence does not justify selecting one of those outcomes as settled.
OpenAI’s general warning about verification gaps should likewise not be mistaken for a specific response to Recht’s post. It acknowledges uncertainty across the collection, rather than answering his objections about this FFT result.
A Large Release Multiplies the Verification Work
The scale of OpenAI’s collection makes this dispute consequential beyond one algorithm.
The repository says approximately 42% of its top-line results are formalized. That figure is not the percentage of manuscripts independently reviewed, and it does not establish the verification status of the FFT paper. More fundamentally, formal proof checking and practical evaluation answer different questions.
A formalization can check a theorem within its stated definitions and assumptions. It does not transform an idealized arithmetic operation into a cheap hardware instruction or establish competitive runtime for realistic inputs.
For a claimed computational improvement, readers need to distinguish at least three things: whether the proof is correct, whether its computational model answers the intended question, and whether its costs permit useful performance. Evidence for one should not stand in for the others.
Publishing manuscripts and supporting artifacts makes scrutiny possible. Publishing hundreds at once also leaves a substantial task for researchers trying to assess correctness, novelty, assumptions, and significance. A catalogue’s size is not a substitute for that work.
For now, Recht’s post supplies a concrete challenge to the practical interpretation of OpenAI’s FFT result, not a verdict on its mathematical validity. The evidence that would change the practical assessment is equally concrete: explicit feasible costs, justified precision requirements, and comparative performance under realistic conditions. Until those are established, an asymptotic improvement should remain a theoretical claim rather than a promised upgrade for FFT users.
