I was working on this week's post on Lean after reading Kevin Hartnett's book The Proof in the Code: How a Truth Machine Is Transforming Math and AI. And then yesterday OpenAI announced a solution to Navier-Stokes, one of the Millennium problems. An incredible accomplishment to say the least. Hours earlier Tristan Buckmaster posted about his progress with Levent Alpöge based on a program started by Diego Córdoba and Luis Martínez-Zoroa, and his interactions with OpenAI. I'm still trying to understand what happened and will write more later but I recommend the Quanta article to get you up to speed.
Lean plays a major role for both projects. OpenAI fully formulated their results in Lean. Buckmaster said they have Lean-verified proofs for the three results they made public but held back on the "blowup for hypo-dissipative Navier Stokes" because the Lean verification has not finished. So it's worth taking a look back.
Leonardo de Moura developed the first version of Lean in 2013 as a Microsoft project for proving code correct. Hartnett tells the story of the people involved in the development of the various versions of Lean capturing the excitements and disagreements. What caught me was the lack of backward compatibility, the definitions and theorems formalized in one version of Lean might break in the next. There was a constant need to get the libraries back up to date until the development stabilized.
The best part of the book focused on some big projects in Lean.
- Tom Hales wanting to convince the world that his proof of the Kepler Conjecture was correct.
- Peter Scholze wanting to convince himself of the correctness of his liquid tensor experiment.
- Kevin Buzzard, Johan Commelin and Patrick Massot formalizing Scholze's Perfectoid Spaces to show Lean can handle modern mathematical objects.
- Terence Tao wanting to formalize in Lean the proof with Tim Gowers, Ben Green and Freddie Manners of the polynomial Freiman-Ruzsa conjecture, just to show it could be done.
And now Lean, particularly in the Navier-Stokes papers, is being used as a time-stamp, a way to claim your theorem before having to write it up properly in an explainable way. Buckmaster even held back a result because it wasn't yet Lean verified. The way we even publish results is a-changing.
I think that Lean made the PCP theorem obsolete, at least there is no need to use it for proofs. I need to find another application for my students when I teach it.
ReplyDelete"I don't expect P vs NP to be solved anytime soon." Was written in a recent post on this blog website. Sure, P vs. NP might be bigger than or less understood than Navier Stokes (although I doubt one can rank these things so easily), but why should we not expect to see a P vs. NP proof any time soon, which uses terms from all the common ideas and theorems that we already know in computational complexity theory and just mixes these up in a way that leads to a correct end result? Maybe all the proof will be in the end is just a loooong series of characters that can be checked in Lean and won't contain anything extremely surprising. Doesn't mean it won't be thought of as a clever proof with a clever proof strategy.
ReplyDeleteHere is that post where I give my reasons. The proof in the end will be a long sequence of characters, but it will have to be surprising because the usual tools won't work.
Deleteto add to what Lance wrote, this particular problem have had some significant progress over the past two decades by humans, it was no longer thought out of reach, the Quanta magazine goes into details.
DeleteThere was already proofs for similar simpler problems, and the reason why OpenAI picked this problem was because they heard humans are close to solve it.
The fact that humans had an approach to the problem is a big part of the story here.
I doubt that OpenAI would spend tens of millions of dollars on P vs. NP when there has been no significant progress on it.
We don't even have any significant progress on the P vs. NP and proving lowerbounds on general circuits for over 40 years.
I think you are not considering P=NP.
Deletethat is the key:
Deletethe space of possible paths is infinite
taking the right path is the difficult part
for Navier-Stokes this path has had become a clear one to explore, you can drop a bunch of AI agents to go explore it.
but for P vs. NP, where is the path that should be explored?
had anyone even succeeded in separating the much much weaker TC0 from NP? i haven't heard a single serious path on that over the last 4 decades.
once you know which path you want to explore, you have reduced the space of search massively and an AI driven heuristic better force search with a verifier can succeed.
the most difficult part of research is knowing what problems are solvable with the current tools you have and what approach you should try.
@Lance, the talking points remind me somewhat of "automated" integration via the Risch algorithm. Basically, it's an automated procedure to find antiderivatives assuming certain constraints... it provides absolutely ZERO human insight nor helps the actual understanding of how we obtained it -- but it doesnt hurt to have it, and to most applied math folks who just want to compute, it's exactly what they need.
DeleteI gave talks at the Simons institute (https://m.youtube.com/watch?v=pa5mURjUNFI) and CSL 2025 (https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.CSL.2025.3) on why using proof assistants in TCS is extra hard.
ReplyDeleteAnd I worked on formalising computational complexity a long time ago, including the first construction of a universal Turing machine that's "good" for both time and space. Our recommendation was "don't do that's, it's too painful" https://dl.acm.org/doi/10.1145/3372885.3373816
Small nitpick: Tom Hales worked mainly in Isabelle/HOL with a bit of (I believe) HOL light. This was before the Lean project was started ;)
I think I first saw your Simons institute talk several months ago when it was linked on the Lean forum, and it made me think that perhaps the best way forward is to side step the painful work of formalizing results in these models / relationships to other models by having LLMs do the hard parts. I would be particularly interested in any dangers you would forsee in that process, if it were to be taken on seriously.
DeleteThank you for quickly answering
ReplyDelete“ longer do you need to write Lean code, any more than you need to write Python code, you can just use AI to generate it. “ -> unless you know lean, you don’t know what you have formalized. There are a number of trivial ways to make mistakes in writing definitions and stating theorems.In Python if you make a mistake you might get tolerable bugs. If you get contradictory or incorrect definitions, everything is wrong.
ReplyDeleteHow confident are we that Navier-Stokes is correct based on just the Lean cert? The Lean compiler does still have bugs, right? I don't seriously doubt it's correct, just wondering what level of certainty we're talking about exactly.
ReplyDeleteAfter chatting with more clued-in people, my impression is that bugs in the Lean compiler are rare enough that they only seem to manifest in adversarial examples. A more likely way for a Lean proof to be invalid is if the problem statement itself was coded into Lean incorrectly. Presumably that's been checked carefully by now for Navier-Stokes.
DeleteI wouldn't put it past an unchecked AI swarm to figure out a way to abuse a bug to make the proof work
DeleteI think it is of utmost importance to read Tristan Buckmaster's response to OpenAI's discovery and recent actions:
ReplyDeletehttps://cims.nyu.edu/~tristanb/statement.pdf
For those unaware of the drama behind this breakthrough, the accusations are great, involve people from the TCS community, and if true, require a swift response.
+1 -- and I would add, if you are still feeding your ideas to these proprietary models, you should stop immediately.
Delete+1000 -- I knew we cannot trust OpenAI and how they use our work. This goes out to the three people one of who I respected who works at OpenAI and is actually overlooking the math progress.
ReplyDeleteI think the rumour mill about how Sam Altman has been leading the team might have been right all along. Not saying that someone else say, Pam Saltman would have done differently, but .... this isn't ending up nicely.
Pam Saltman and crew might be reading this blog as you can see "Pam's" latest stance, we are "open" to slowing cutting edge AI down ...
Deleteoh boi, i have been in this business long enough to feel a certain repulsive urge the way people use AI these days. What does this even mean? Remember back at Dartmouth when we coined the term AI and its meaning? Then stagnation followed and we had AI systems doing routine automation. Then deep learning term went popular but that for some people wasn't AI.
What is cutting edge AI, is this AI that cuts and makes one bleed?
https://cims.nyu.edu/~tristanb/statement.pdf
ReplyDeleteThey have solved the problem, but they did not advance the science in doing so.
ReplyDeletehttps://mathstodon.xyz/@tao/117244102901892965
so did perelman advance science or did he just solve the problem?
Deletehttps://mathandai.org/
DeleteHere is a statement on it from the Fields Medalists.
It might help you understand what people mean when they say it is not advancing science.
These AI companies are the least trustworthy organizations in the world, if the future of AI's impact on humanity is in their hands, we are definitely doomed.
Perelman introduced new techniques for understanding and controlling Ricci flow, and those techniques have seen other applications. So yes, he advanced the science.
DeleteI believe the "experiment" in "liquid tensor experiment" refers to experimenting with Lean formalization of cutting-edge mathematics, so saying Scholze was trying to convince himself of the correctness of his liquid tensor invariant is circular. I think "convince himself of the correctness of his proof of a theorem about liquid vector spaces" would be closer.
ReplyDeleteIf you're interested in the de Bruijn factor in Lean of results in complexity theory, you can look at https://github.com/SamuelSchlesinger/complexitylib
ReplyDeleteThis library is pretty heavily AI-driven which in my experience is much more of an important influence on the size of the code than the subject matter.
I am not qualified enough to do so but I still would like to congratulate everyone involved in solving the Navier-Stokes Millenium Problem. As for Lean, I am investigating how QPrograms a part of QSpire Algebra could work together with Lean. PS: Really love this blog. Keep up the great work.
ReplyDeleteToo bad we do not still have Tom Lehrer around, so he could work up a new song, LobAIchevsky.
ReplyDeleteA different perspective on AI and math:
ReplyDeletehttps://proofsandprompts.com/2026/09/14/a-beginning-for-mathematics/