I don't want to formalize any of my work on mathematics.
-
@markusde Have you seen what can be done with this nowadays https://theoremlabs.com/blog/lf-lean/ ?
@mevenlennonbertrand I've read that article rocq-lean-import was the only interesting thing in it
-
@johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker I agree with @andrejbauer 's take, including his skepticism of my comments on Lean choking things off: we're talking (implicitly) about different time scales. I'm witnessing a current funnelling of resources, which will cause short-term pain. Indeed this is unlikely to remain 'forever'.
@johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker On the more optimistic side:
- there is a lot of structure to mathematics, which is currently not very well leveraged, i.e. Universal Algebra and its many generalizations. But people are working on that (myself included).
- regardless of what some say, there is a lot of 'computational mathematics', which is currently not well supported by any system, and essentially eschewed by Lean+Mathlib. That requires thinking differently. Again, people are working on that.
- in fact, there is quite a bit more to math in general -- see the Tetrapod approach for one.
To me, what's really missing are experts in designing UX having a solid look at mechanized mathematics tools. For that to bear fruit, experts in requirements analysis need to better understand the full "mathematics workflow" -- where proof is just one small aspect. It might indeed be the most time-consuming part, but it is not necessarily where the most value lies. [See LaTeX as an example of a strong value proposition that has completely changed the practice of mathematics, but in a surreptitious way, as it is essentially invisible wrt "mathematical thought". Its effect is no less important.]
-
@mevenlennonbertrand I've read that article rocq-lean-import was the only interesting thing in it
@mevenlennonbertrand Porting a bunch of theorem statements and then saying it's "verified" is... bold
-
This is just the beginning.
Current systems are the FORTRAN and Pascal of proof systems; they are for building pyramids--imposing, breathtaking, static structures built by armies pushing heavy blocks into place.
What we need is for someone to invent the Lisp of proof systems. Something that helps individuals to think new thoughts.
@maxpool @johncarlosbaez @dougmerritt
I mean, Maxima was literally written in the late 60's in LISP to give people help thinking new thoughts (beyond what they could reasonably accurately do by hand)
-
@johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker On the more optimistic side:
- there is a lot of structure to mathematics, which is currently not very well leveraged, i.e. Universal Algebra and its many generalizations. But people are working on that (myself included).
- regardless of what some say, there is a lot of 'computational mathematics', which is currently not well supported by any system, and essentially eschewed by Lean+Mathlib. That requires thinking differently. Again, people are working on that.
- in fact, there is quite a bit more to math in general -- see the Tetrapod approach for one.
To me, what's really missing are experts in designing UX having a solid look at mechanized mathematics tools. For that to bear fruit, experts in requirements analysis need to better understand the full "mathematics workflow" -- where proof is just one small aspect. It might indeed be the most time-consuming part, but it is not necessarily where the most value lies. [See LaTeX as an example of a strong value proposition that has completely changed the practice of mathematics, but in a surreptitious way, as it is essentially invisible wrt "mathematical thought". Its effect is no less important.]
@johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker On a more personal note, I'm strongly enjoying that all this work on proof assistants is forcing many many more people to think about meta-mathematics (and I don't mean just logic here, but all aspects of 'mathematics' as a subject of study.) /end
-
@JacquesC2 @johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker Lean is worse, but, infamously, https://en.wikipedia.org/wiki/Worse_is_better
@markusde @JacquesC2 @johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker it is absolutely wild that lean is (unironically?) being used as an example of worse is better.
-
@mevenlennonbertrand Porting a bunch of theorem statements and then saying it's "verified" is... bold
@markusde Isn't the point that having a proof on the Rocq side + a proof that the statement translated from Lean is equivalent to the Rocq one makes it reasonable to not translate the whole proof? I find it not quite fully satisfying, but the approach sounds honestly very reasonable to me.
-
@johncarlosbaez @dougmerritt @MartinEscardo @JacquesC2 @pigworker Somewhat unexpectedly, I find myself on the same side as @xenaproject on this one, I suppose because I read "the right way" differently from @johncarlosbaez
Formalized mathematics makes us think "the right way" in the sense that it requires mental hygiene, it encourages better organization, it invites abstraction, and it demands honesty.
Formalized mathematics does not at all impose "One and Only Truth", nor does it "nail things down with rigidity" or "impose concensus". Those are impressions that an outsider might get by observing how, for the first time, some mathematicians have banded together to produce the largest library of formalized mathematics in history. But let's be honest, it's miniscule.
Even within a single proof assistant, there is a great deal of freedom of exploration of foundations, and there are many different ways to formalize any given topic. Not to mention that having several proof assistants, each peddling its own foundation, has only contributed to plurality of mathematical thought.
Current tools are relatively immature and do indeed steal time from creative thought to some degree, although people who are proficient in their use regularly explore mathematics with proof assistants (for example @MartinEscardo and myself), testifying to their creative potential.
Finally, any fear that Mathlib and Lean will dominate mathematical thought, or even just formalized mathematics, is a hollow one. Mathlib will soon be left in the dust of history, but it will always be remembered as the project that brought formalized mathematics from the fringes of computer science to the mainstream of mathematics.
@andrejbauer why will Mathlib soon be left in the dust of history?
-
@markusde @JacquesC2 @johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker it is absolutely wild that lean is (unironically?) being used as an example of worse is better.
@sandmouth @JacquesC2 @johncarlosbaez @dougmerritt @MartinEscardo @andrejbauer @pigworker I mean... I'm serious about it. I've seen really convincing arguments from type theorists about how Lean's type theory is missing features (transitive defeq, decidable defeq, consistency with various axioms). Some of the missing features are just mistakes, but some of them are made in the interest of usability or simplicity or speed or whatnot.
Personally, I don't think has decisively shown that these things _aren't_ in conflict, so that is the sense in which I see Lean as worse and better. Idk, just my opinion.
-
@markusde Isn't the point that having a proof on the Rocq side + a proof that the statement translated from Lean is equivalent to the Rocq one makes it reasonable to not translate the whole proof? I find it not quite fully satisfying, but the approach sounds honestly very reasonable to me.
@mevenlennonbertrand I guess I don't understand their article. I can see how you'd verify that a round-trip Rocq translation is correct (ie. identical) but doesn't that say nothing about the correctness of your Lean code when linked against other Lean code?
Adding to the TCB is not that interesting to me.
-
@mevenlennonbertrand I guess I don't understand their article. I can see how you'd verify that a round-trip Rocq translation is correct (ie. identical) but doesn't that say nothing about the correctness of your Lean code when linked against other Lean code?
Adding to the TCB is not that interesting to me.
@markusde I guess it says that :
- the definitions give you objects which once roundtripped are isomorphic to the original ones ; not the best specification, but rather solid (it rules out everything being unit or something, and is especially fine if you also translate the various operations/basic proofs which encode that they behave the way one expects)
- the lemmas you admit on the Lean side are logically equivalent (up to Lean -> Rocq translation) to ones which are proven, which to me makes them very reasonable to assumeOf course that brings the Lean -> Rocq translation to the TCB, as well as Rocq, but I still feel this is ok?
And I don't see how the liking with other Lean code changes anything, you can treat the translated code as some sort of opaque module with a bunch of definitions and proofs and use that opaquely, just as you would any other Lean module? Except in this one the proofs are not there, they're on the Rocq side
-
@johncarlosbaez @dougmerritt @MartinEscardo @JacquesC2 @pigworker Somewhat unexpectedly, I find myself on the same side as @xenaproject on this one, I suppose because I read "the right way" differently from @johncarlosbaez
Formalized mathematics makes us think "the right way" in the sense that it requires mental hygiene, it encourages better organization, it invites abstraction, and it demands honesty.
Formalized mathematics does not at all impose "One and Only Truth", nor does it "nail things down with rigidity" or "impose concensus". Those are impressions that an outsider might get by observing how, for the first time, some mathematicians have banded together to produce the largest library of formalized mathematics in history. But let's be honest, it's miniscule.
Even within a single proof assistant, there is a great deal of freedom of exploration of foundations, and there are many different ways to formalize any given topic. Not to mention that having several proof assistants, each peddling its own foundation, has only contributed to plurality of mathematical thought.
Current tools are relatively immature and do indeed steal time from creative thought to some degree, although people who are proficient in their use regularly explore mathematics with proof assistants (for example @MartinEscardo and myself), testifying to their creative potential.
Finally, any fear that Mathlib and Lean will dominate mathematical thought, or even just formalized mathematics, is a hollow one. Mathlib will soon be left in the dust of history, but it will always be remembered as the project that brought formalized mathematics from the fringes of computer science to the mainstream of mathematics.
@andrejbauer @johncarlosbaez @dougmerritt @JacquesC2 @pigworker @xenaproject
It is not inconceivable that one day in the not-too-distant future, proof assistants will be able to "understand" proofs written in sufficiently careful, informal, mathematical vernacular and translate it to a suitable formal language.
And this formal language doesn't need to be fixed. The mathematician just chooses a foundation, or, in case they don't care, they let the proof assistant choose a suitable one for the informal (but hopefully rigorous) mathematics at hand.
I don't mean AI, but people are certainly trying this with so-called AI nowadays (personally, I think this is the wrong approach, but **I don't want** this to become the subject of discussion here).
In any case, a person will need to check that the definitions and the statements of the theorems and constructions are correctly translated (*). Then the formal proofs obtained from informal proofs don't need to be checked by people.
(*) At least at the beginning. For example, we now trust that C compilers produce correct machine code and don't check it ourselves.
In any case, all of the above can happen only step by step, and currently we are at an important step, I think, where the first were in the 1960's by de Bruijn.
As I said before, I use proof assistants as smart blackboards. If I could get interactive help while I write in mathematical vernacular, I would immediately adopt this incredible new proof assistant.
And, I repeat, I don't mean the kind of non-help I get from ChatGPT, Gemini, Claude, DeepSeek, or what-you-have - I feel I help them rather than the other way round.
I mean the kind of help I already get in non-AI-based proof assistants
-
@RobJLow @johncarlosbaez Well, I heard Kevin talk about problems in the Langlands program where Jim Arthur claimed big results in a number of really meaty "forthcoming" papers and people took his word, and then it turned out there were big problems. In that kind of mathematics, the problem wasn't that it wasn't formalised, but that people are perhaps getting a bit too confident.....
@highergeometer @RobJLow - soon we will give mathematicians brain implants that make their glasses flash a red warning light when they state any result that hasn't been formalized, and this problem will be solved.
-
@markusde I guess it says that :
- the definitions give you objects which once roundtripped are isomorphic to the original ones ; not the best specification, but rather solid (it rules out everything being unit or something, and is especially fine if you also translate the various operations/basic proofs which encode that they behave the way one expects)
- the lemmas you admit on the Lean side are logically equivalent (up to Lean -> Rocq translation) to ones which are proven, which to me makes them very reasonable to assumeOf course that brings the Lean -> Rocq translation to the TCB, as well as Rocq, but I still feel this is ok?
And I don't see how the liking with other Lean code changes anything, you can treat the translated code as some sort of opaque module with a bunch of definitions and proofs and use that opaquely, just as you would any other Lean module? Except in this one the proofs are not there, they're on the Rocq side
@mevenlennonbertrand I am not comfortable with having that added to the TCB, so, getting back to my initial comment I would not call it "verified" given how easy it is to get wrong! Their article brings up several differences between the Lean and Rocq type theory... can they be sure they caught them all? Apply their technique to a proof development in a different language that is not classically valid. What goes wrong? What if all the definitions they choose to port are round-trippable but some of them are not true????
The answer to this rhetorical question is probably that "they wouldn't trust that" but I think the translation is subtle enough that I wouldn't put faith in it.
-
@mevenlennonbertrand I am not comfortable with having that added to the TCB, so, getting back to my initial comment I would not call it "verified" given how easy it is to get wrong! Their article brings up several differences between the Lean and Rocq type theory... can they be sure they caught them all? Apply their technique to a proof development in a different language that is not classically valid. What goes wrong? What if all the definitions they choose to port are round-trippable but some of them are not true????
The answer to this rhetorical question is probably that "they wouldn't trust that" but I think the translation is subtle enough that I wouldn't put faith in it.
@mevenlennonbertrand
There could be engineering value in this as a starting point to porting complete proofs, though ofc that is not demonstrated until you actually do the proofs. For example, I would consider a tool that translates Rocq canonical structures hierarchies into it's type-theoretically similar Lean code _wrong_, because in Lean, you want to use typeclasses 99% of the time. I'll reserve judgement until they fill in the gaps. -
@andrejbauer @johncarlosbaez @dougmerritt @JacquesC2 @pigworker @xenaproject
It is not inconceivable that one day in the not-too-distant future, proof assistants will be able to "understand" proofs written in sufficiently careful, informal, mathematical vernacular and translate it to a suitable formal language.
And this formal language doesn't need to be fixed. The mathematician just chooses a foundation, or, in case they don't care, they let the proof assistant choose a suitable one for the informal (but hopefully rigorous) mathematics at hand.
I don't mean AI, but people are certainly trying this with so-called AI nowadays (personally, I think this is the wrong approach, but **I don't want** this to become the subject of discussion here).
In any case, a person will need to check that the definitions and the statements of the theorems and constructions are correctly translated (*). Then the formal proofs obtained from informal proofs don't need to be checked by people.
(*) At least at the beginning. For example, we now trust that C compilers produce correct machine code and don't check it ourselves.
In any case, all of the above can happen only step by step, and currently we are at an important step, I think, where the first were in the 1960's by de Bruijn.
As I said before, I use proof assistants as smart blackboards. If I could get interactive help while I write in mathematical vernacular, I would immediately adopt this incredible new proof assistant.
And, I repeat, I don't mean the kind of non-help I get from ChatGPT, Gemini, Claude, DeepSeek, or what-you-have - I feel I help them rather than the other way round.
I mean the kind of help I already get in non-AI-based proof assistants
@andrejbauer @johncarlosbaez @dougmerritt @JacquesC2 @pigworker @xenaproject
And let's not forget.
Everybody here and elsewhere says Lean, Lean, Lean.
Before Lean, we have a long list of successful proof assistants.
In particular, Lean is based on both Rocq (formerly known as Coq) *and* the foundations of Rocq, namely the "calculus of inductive constructions".
Lean is Rocq with a new skin and a new community, based on the very same foundations and approaches.
I can say this without any conflict of interest, because I prefer Agda instead, which is based on a different foundation, namely MLTT.
And this preference is based on the kind of mathematics *I* prefer (constructive, suitable for being interpreted in any (infinity) topos, in the (in)formal language of HoTT/UF).
-
@andrejbauer @johncarlosbaez @dougmerritt @JacquesC2 @pigworker @xenaproject
And let's not forget.
Everybody here and elsewhere says Lean, Lean, Lean.
Before Lean, we have a long list of successful proof assistants.
In particular, Lean is based on both Rocq (formerly known as Coq) *and* the foundations of Rocq, namely the "calculus of inductive constructions".
Lean is Rocq with a new skin and a new community, based on the very same foundations and approaches.
I can say this without any conflict of interest, because I prefer Agda instead, which is based on a different foundation, namely MLTT.
And this preference is based on the kind of mathematics *I* prefer (constructive, suitable for being interpreted in any (infinity) topos, in the (in)formal language of HoTT/UF).
@MartinEscardo @andrejbauer @johncarlosbaez @dougmerritt @JacquesC2 @pigworker @xenaproject
while I mostly agree, I think Lean also inherits many ideas from Isabelle, not about foundations at all but instead about things like proof search and automation.
-
I don't want to formalize any of my work on mathematics. First because, as Emily Riehl notes, formalization tends to impose consensus. And second, because I find it boring. It steals time from creative thought to nail things down with more rigidity than I need or want.
Kevin Buzzard says "It forces you to think about mathematics in the right way." But there is no such thing as "the" right way to think about mathematics - and certainly not one that can be forced on us.
In Math, Rigor Is Vital. But Are Digitized Proofs Taking It Too Far? | Quanta Magazine
The quest to make mathematics rigorous has a long and spotty history — one mathematicians can learn from as they push to formalize everything in the computer program Lean.
Quanta Magazine (www.quantamagazine.org)
@johncarlosbaez What I find interesting about this is that during my mathematical training I was taught there is but one way to do mathematics: ZFC. When I got to meet people working in proof verification I learnt that there is a whole world of formalisms out there.
-
@highergeometer @RobJLow - soon we will give mathematicians brain implants that make their glasses flash a red warning light when they state any result that hasn't been formalized, and this problem will be solved.
@johncarlosbaez your suggestion made me think of this Far Side cartoon:
https://static1.cbrimages.com/wordpress/wp-content/uploads/2023/05/the-far-side-didnt-wash-hands.jpg -
@johncarlosbaez your suggestion made me think of this Far Side cartoon:
https://static1.cbrimages.com/wordpress/wp-content/uploads/2023/05/the-far-side-didnt-wash-hands.jpg@johncarlosbaez uncomfortable in many ways, yes.
