This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.
Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.
We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:
-
Shaming.
-
Attempting to 'build consensus' or enforce ideological conformity.
-
Making sweeping generalizations to vilify a group you dislike.
-
Recruiting for a cause.
-
Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.
In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:
-
Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.
-
Be as precise and charitable as you can. Don't paraphrase unflatteringly.
-
Don't imply that someone said something they did not say, even if you think it follows from what they said.
-
Write like everyone is reading and you want them to be included in the discussion.
On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.
Jump in the discussion.
No email address required.
Notes -
Navier-Stokes Millenium Problem Solved by GPT
OpenAI says they solved the Navier-Stokes Millenium Prize problem with an internal model that is more powerful than GPT6, so a GPT 7 candidate or something close. OpenAI has been on fire lately really casting a shadow on Anthropic. First the hugging face incident, now the first to crack the Millenium prize problems.
As for the solution to the problem, they are claiming that smoothness is disproved and that the equations do break down.
They say that the equation can develop a singularity, which apparently means it is not a perfect model.
This is very exciting to me as I believe it to be the first scientific result of an AI model. Previous results have been basically irrelevant to the sciences. However, this result is of course still completely symbolic in nature, which is not surprising because LLMs are not embodied enough to collect data and analyze it autonomously.
While they are generating amazing PR recently, I will say GPT-6 is somewhat disappointing for coding. It is not the same leap that 5.5 to 5.6 sol was. It would appear that the models are getting better at running very long context chains while efficiency improvements and refinements in lower level tasks are lacking. Still, it's great work from OpenAI and it's plausible to me that if there's no singularity in general by 2030, there will be for mathematicians. They will no longer be meaningful for producing math, rather they will only be humans who understand it.
May be tossing egg on my face, but I'll post this anyway:
There's a decent chance this proof is not valid. It's formalised in Lean 4, yes, but we also had a Lean-verified proof of the Collatz conjecture a couple months ago that turned out to be spurious (they didn't actually find a proof; they found a bug in Lean).
That proof was 320 lines. This Navier-Stokes proof is 1.6 million lines, and according to their README, requires 100GB to even check. Thanks to somebody eating all the ram, my PC does not presently have 100GB, so I can't run Lean myself to check it. But I will point out that the README explicitly mentions Lean 4.32.2, and the release notes for Lean 4.33.1 mention two soundness bugs fixed, so... it sure looks like there are exploitable soundness bugs in the version they used for this proof.
And if an LLM can find a soundness bug in 320 lines, surely it can sneak one into 1.6 million lines.
Who cares how many lines it is? If it doesn't check out with a more recent kernel, that's obviously bad,and ideally it would be checked with several independent implementations of the Lean kernel, as Anthropic did with their 13M line autoformalization of Fermat's last theorem.
But if it checks out it doesn't matter how long the proof is, what matters is whether the statement was formalized correctly. AFAICT they reused a formalization of the stamenet made previously and independently by an open source project, so it's unlikely there's something wrong there.
Of course, the 2M line proof is unenlightening in terms of why the proof is true, but hopefully the next stage in AI mathematics is cleaning up these monster proofs for human consumption.
I think it matters, in both a philosophical sense, and a practical sense, that it's not checkable by a human.
I know the arguments made around the 4-color theorem automated proofs back in 2005 sounded a bit silly, but they seem all the more pertinent now:
Both of these are very much applicable to AI assisted proofs and to have practical ramifications for mathematical applications.
Now will that stop people from doing computer assisted anything? Certainly not, and there is value to knowledge, regardless of how you acquired it. But we'll have to atone for our shortcuts one way or another.
I do believe I covered this.
It's a lot easier to check and verify the Lean kernel compared to, say, Wiles' proof of Fermat's last theorem. You can't get away from the trust problem. If anything, formalized proofs require less trust.
Ultimately this is of course why Metaphysical Skepticism can stand up even to Aristotelians, the possibility of error is always there. But the risk when trusting machines and when trusting men is different in shape to the point that I would argue it's a difference in nature.
This is best understood by people when we propose mathematical methods for voting: the attack surface of an effective cryptosystem for well formed electronic voting is so large compared to that of transparent urns and paper that nobody sane claims the advantages are worth the tradeoff.
I claim this tradeoff also applies to essentially all forms of computer assisted mathematics. That the complexity and attack surface of the necessary computer systems is extremely large in comparison to the restrained complexity of checking human proofs.
That only few can even understand such proofs cannot be an argument since this applies to these computer systems as well. It is in fact much worse because instead of having to trust a handful of mathematicians, you need to trust that handful AND many other handfuls along your supply chain.
This is of course not a new argument but all or most future mathematical knowledge being vulnerable to supply chain attacks to this degree is a novelty.
You've basically got it backwards. It's in fact much simpler to validate the Lean kernel than a complicated proof like that of FLT or NV and many more people can do it. On top of that, the Lean kernel can be hardened through continual adversarial attacks in ways that human proof checking cannot, proofs can be checked against multiple clean room Lean implementations, etc.
I'm afraid it's not so simple.
What you're saying is that Lean's soundness relies solely on the soundness of the kernel. This is true and is a constructive property of provers structured like Lean. But moreover you're claiming implicitly this is true insofar as the kernel code has no soundness bug. That however is false. Unsoundness can be introduced in Lean by non-Lean code.
Lean's kernel is written in C++ and runs on a specific hardware and software stack.
Per Thompson's well known argument, the behavior of compiled software can be arbitrarily changed by subtle changes in its compiler. This means that any change in:
Any of these can, and can in covert ways, result in unsoundness in a run of Lean.
Moreover, and in turn, any change in whichever programs compiled any element of the chain that created these artifacts, can have the same effect. Including any earlier versions of any involved compilers that compiled later versions being used at any point.
Ergo, any trust put in a verification made by Lean is implicity a trust in millions of lines of code which were not written by Lean authors.
Moreover, even if Lean were self hosting and bootsrappable, along the lines of a further and more production ready Lean4Lean, that still wouldn't remove the necessary trust in the initial bootstrap and its software and hardware setup, on top of any further hardware setup you're running the resulting binary on.
So no, it's not a complicated proof versus a relatively small kernel codebase. It's the millions of lines constituting at minimum an entire computing stack (and practically many) versus a complicated proof.
And these are not theoretical attacks, we had a recent high profile case a few years ago and landed in many distro's sshd builds through the vector i'm describing here.
Nor is tampering with mathematicians to steer them towards untruths unprecedented, and in fact the precedent is literally the kind of actor that has access to the sophistication and 0-days necessary for such an attack.
Technically true, practically irrelevant. Compilers can and are tested and are under even greater scrutiny than Lean. They're used in applications much more serious than what's basically glorified recreational mathematics.
I'm puzzled that you conflate the Ken Thompson hack, which is an undetectable modification of the toolchain, with a pedestrian supply chain attack like a CVE-2024-3094.
The practical obstacles to doing a Ken Thompson hack are immense, which is why it's never been done. CVE-2024-3094 is a completely different vector that would be impossible if ssh checked every change going into its dependencies, which is easily done in the age of machine intelligence.
And what libraries does the Lean kernel depend on? Just GMP, which in turn depends only on the C++ standard library. Not a lot of room for supply chain attacks, you're basically stuck trying to compromise every compiler on the planet, including all the already built binaries, without anyone noticing, despite the fact that everyone and their mother is watching every patch going into LLVM and GCC. I know they say that academic politics are so bitter because the stakes are so low, but you have to have a sense of proportion here.
You'd probably have an easier time convincing mathematicians of some bullshit - no complicated attacks required.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link