4 ms·

Thanks for responding. Here’s what I mean about proofs. I learned how to do them in college, and in the early classes we got a lot of leeway on grading, and the

by _05hb 2y ago

Thanks for responding. Here’s what I mean about proofs. I learned how to do them in college, and in the early classes we got a lot of leeway on grading, and then as we moved up they expected more and more rigor. But it was still a conversation, like if I got dinged a few points on an exam question, I could take it to my professor and make my argument that my proof was valid, and I might get a point or two back. The proof-as-mathematical-object either exists or does not, but deciding whether my answer pointed to that proof was a social exercise. Professional mathematicians also cut either other some slack. Most proofs published today have small errors — typographical, skipped steps, etc — and those bugs are never fixed. Despite the bugs, we’re confident in the results, and that confidence is a product of social consensus. On the other hand, also in college, I had my programming classes, where I would turn in my code and they ran it through a test harness, and my grade was the number of tests that passed. So, if there was a syntax error, I got a 0. This was brutally harsh to the good students who attended every class, took notes, and studied, but who did not conform their minds to writing code. But that’s how we learn programming, because the compiler doesn’t care about intentions and “almost” is worth nothing. Alan Perlis said “programming is an unnatural act.” It’s not harder than other jobs — in many ways it’s easier — but it’s much weirder, and it makes you weird. Professional programmers write bugs, constantly: why can’t they just write the code, without the bugs? Because our minds aren’t built that way.

cauch 2y ago
> I learned how to do them in college ... I have the opposite experience: when learning physics, math was really difficult to negotiate with the professor, because it is mathematically correct or not. They had their table that said "if they have done this, X points, otherwise 0", which is an exactly equivalent system as the one where your grade corresponds to the number of test your software passes. It was easier to negotiate points in the computer science lectures, where I could argue that having used some concepts shown in the lecture (using object-oriented, recursive functions, ...) was worth some point even if I did not finish my algorithm. I think your experience (and mine) is just because you have been exposed to "beginner tests / optional course" in one field and "higher grade / main course" in the other. Beginner or optional lectures tend to give more leeway. > Professional mathematicians also cut either other some slack. Most proofs published today have small errors ... That's just not true: if there is an error, the result is not reliable, and it is therefore extremely important to identify them. It does not mean that the person who made the mistake will be thrown out of the field (of course not, every mathematician has made mistake some time, it's part of the job). And by the way, I wonder how you are in position to know that. You are claiming that "those bugs are never fixed". I've observed math-oriented conferences where some of the talks were all about discussing these bugs. I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community. It's as stupid as saying "firefox 6 has a bug, it never has been fixed (but of course I did not look if they released new version)". But the problem with this argument is that you are comparing that to a field _that is build around the fact that bugs will always exist_. You have debugger, code review, testing environment, and despite that, every released software always end up have some bug fix updates. You are arguing that it's different for mathematicians because their publications contain errors (which is at best a very misleading description of the reality), while at the same time, DEVELOPERS RELEASED SOFTWARE WITH BUGS ALL THE TIME, in a way bigger rate and with sometimes way less following (some bugs are even some times considered "will not fix")
- _05hb 2y ago
  Thanks again for responding. You gave me a lot to think about. It seems like there isn’t much daylight between our positions, and in any case I’m sure nobody else is reading, so I’ll wrap it up here for any future spelunkers. I think I’m on solid ground asserting that it’s common knowledge that most proofs have errors. The reason is that professional mathematicians tell us so. Here’s Terry Tao: https://terrytao.wordpress.com/advice-on-writing-papers/proofread-and-double-check-your-paper-before-submission/ https://terrytao.wordpress.com/advice-on-writing-papers/proo.... Notice how Tao acknowledges that papers “full of errors” are sometimes not corrected before publication. What does that mean for proofs which have only one minor error, and referees less exacting than Terry Tao? Chapter 7 of Simon Singh’s book on Fermat’s Last Theorem is also illustrative (Singh liberally quotes from his sources directly so there is no question about what the mathematicians thought). After Wiles submitted his manuscript to Inventiones Mathematicae, the referees began finding mistakes almost immediately and were in constant communication with Wiles to get them corrected. Wiles worked on his proof for seven years; nobody thought there was anything wrong with his manuscript having a lot of errors. How probable is it that we found every error in the Wiles proof? Here’s a good MathOverflow question on the topic: https://mathoverflow.net/questions/338607/why-doesnt-mathematics-collapse-even-though-humans-quite-often-make-mistakes-in https://mathoverflow.net/questions/338607/why-doesnt-mathema.... Lots of good responses, and links. What stands out to me is that none of the top answers say “that’s just not true.” Instead those answers about why math proofs “work” even though they’re not completely, rigorously, “correct.” My big point is that in math, some mistakes are trivial, and others are serious. The job of determining which is which is a job for humans — as you point out! — because it’s a topic for conference talks. But in programming, humans don’t decide how serious a mistake is — the computer does, by what it does. Typo in a code comment? No worries. Typo in a variable name? Broken program. If you abbreviate Norway to NOR in your YAML file, that’s cool. Abbreviate it to NO, and there goes your afternoon (because YAML translates NO to false). It’s the capriciousness, not the difficulty, that separates how people learn the two fields. Debuggers, code review, and testing environments are primarily professional tools — they aren’t used by learners. By the time a learner of programming gets those tools, the damage is already done; they’re already weirdos, conditioned to accept the output of the computer no matter how capricious, and rewrite their code however it takes to get their programs to work, even if it doesn’t “make sense.” > I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community. I don’t know what you’re trying to assert. I’m part of the scientific community. Yes, I’ve written code based on proofs that turned out to have flaws, and then I went and updated the code. The most fun one to talk about would be this one from 2006: https://research.google/blog/extra-extra-read-all-about-it-nearly-all-binary-searches-and-mergesorts-are-broken/ https://research.google/blog/extra-extra-read-all-about-it-n... Anyway thanks again for reading. I had a lot of fun writing up these comments & reading what folks and had to say.

by _05hb 2y ago

cauch 2y ago

> I learned how to do them in college ... I have the opposite experience: when learning physics, math was really difficult to negotiate with the professor, because it is mathematically correct or not. They had their table that said "if they have done this, X points, otherwise 0", which is an exactly equivalent system as the one where your grade corresponds to the number of test your software passes. It was easier to negotiate points in the computer science lectures, where I could argue that having used some concepts shown in the lecture (using object-oriented, recursive functions, ...) was worth some point even if I did not finish my algorithm. I think your experience (and mine) is just because you have been exposed to "beginner tests / optional course" in one field and "higher grade / main course" in the other. Beginner or optional lectures tend to give more leeway. > Professional mathematicians also cut either other some slack. Most proofs published today have small errors ... That's just not true: if there is an error, the result is not reliable, and it is therefore extremely important to identify them. It does not mean that the person who made the mistake will be thrown out of the field (of course not, every mathematician has made mistake some time, it's part of the job). And by the way, I wonder how you are in position to know that. You are claiming that "those bugs are never fixed". I've observed math-oriented conferences where some of the talks were all about discussing these bugs. I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community. It's as stupid as saying "firefox 6 has a bug, it never has been fixed (but of course I did not look if they released new version)". But the problem with this argument is that you are comparing that to a field _that is build around the fact that bugs will always exist_. You have debugger, code review, testing environment, and despite that, every released software always end up have some bug fix updates. You are arguing that it's different for mathematicians because their publications contain errors (which is at best a very misleading description of the reality), while at the same time, DEVELOPERS RELEASED SOFTWARE WITH BUGS ALL THE TIME, in a way bigger rate and with sometimes way less following (some bugs are even some times considered "will not fix")

_05hb 2y ago
Thanks again for responding. You gave me a lot to think about. It seems like there isn’t much daylight between our positions, and in any case I’m sure nobody else is reading, so I’ll wrap it up here for any future spelunkers. I think I’m on solid ground asserting that it’s common knowledge that most proofs have errors. The reason is that professional mathematicians tell us so. Here’s Terry Tao: https://terrytao.wordpress.com/advice-on-writing-papers/proofread-and-double-check-your-paper-before-submission/ https://terrytao.wordpress.com/advice-on-writing-papers/proo.... Notice how Tao acknowledges that papers “full of errors” are sometimes not corrected before publication. What does that mean for proofs which have only one minor error, and referees less exacting than Terry Tao? Chapter 7 of Simon Singh’s book on Fermat’s Last Theorem is also illustrative (Singh liberally quotes from his sources directly so there is no question about what the mathematicians thought). After Wiles submitted his manuscript to Inventiones Mathematicae, the referees began finding mistakes almost immediately and were in constant communication with Wiles to get them corrected. Wiles worked on his proof for seven years; nobody thought there was anything wrong with his manuscript having a lot of errors. How probable is it that we found every error in the Wiles proof? Here’s a good MathOverflow question on the topic: https://mathoverflow.net/questions/338607/why-doesnt-mathematics-collapse-even-though-humans-quite-often-make-mistakes-in https://mathoverflow.net/questions/338607/why-doesnt-mathema.... Lots of good responses, and links. What stands out to me is that none of the top answers say “that’s just not true.” Instead those answers about why math proofs “work” even though they’re not completely, rigorously, “correct.” My big point is that in math, some mistakes are trivial, and others are serious. The job of determining which is which is a job for humans — as you point out! — because it’s a topic for conference talks. But in programming, humans don’t decide how serious a mistake is — the computer does, by what it does. Typo in a code comment? No worries. Typo in a variable name? Broken program. If you abbreviate Norway to NOR in your YAML file, that’s cool. Abbreviate it to NO, and there goes your afternoon (because YAML translates NO to false). It’s the capriciousness, not the difficulty, that separates how people learn the two fields. Debuggers, code review, and testing environments are primarily professional tools — they aren’t used by learners. By the time a learner of programming gets those tools, the damage is already done; they’re already weirdos, conditioned to accept the output of the computer no matter how capricious, and rewrite their code however it takes to get their programs to work, even if it doesn’t “make sense.” > I'm sure if you even have an example of such not-fixed-error, you have absolutely no idea how it was treated later by the scientific community. I don’t know what you’re trying to assert. I’m part of the scientific community. Yes, I’ve written code based on proofs that turned out to have flaws, and then I went and updated the code. The most fun one to talk about would be this one from 2006: https://research.google/blog/extra-extra-read-all-about-it-nearly-all-binary-searches-and-mergesorts-are-broken/ https://research.google/blog/extra-extra-read-all-about-it-n... Anyway thanks again for reading. I had a lot of fun writing up these comments & reading what folks and had to say.