3 ms·

OP here. My point was that if you want to be better at math, then you need to get comfortable with proofs. There are lots of instances of using math for useful

by j2kun 14y ago

OP here. My point was that if you want to be better at math, then you need to get comfortable with proofs. There are lots of instances of using math for useful things, but if you don't do proofs you won't get any better at understanding mathematics. There are a lot of times when people want to know more about a particular mathematical fact (they genuinely want to understand why it is the way it is) but the minute you tell them, they stop wanting to hear it. This is what I think is ludicrous. The for loop analogy may be a bit of a stretch, but the reasons for it are as wacky as for the mathematical syntax of inventing or dropping indices. Literally the C99 standard says that if a test expression is missing in a for loop, it's replaced by a nonzero constant. In my mind as a programmer and as a mathematician, that's as arbitrarily confusing as dropping the limits of an indexing variable in a summation. They both just allow you to write/type less and have the expression still mean something.

dxbydt 14y ago
>you need to get comfortable with proofs True, but this is simply not the point of programming/CS. Back in grad school in CS, we used leiserson. Leiserson has proof of quicksort! I mean, that's fucking crazy. He mathematically derives amortized runtime of quicksort.I really loved leiserson. But even my professors hated it...they'd say, lets skip over the proof section, its not important. Nowadays people use Skeina. Skeina is like a storybook. It tells you - do this, get that, if you want to know more, read leiserson! So skeina basically punts. This is why everybody loves skeina, because no proofs. Just straight algorithms that can be translated to code. Skeina is slightly better than Numerical Recipes cookbook, in that it tells you what to do & points you to the why, but doesn't tell you the why. But math is all about why. Now look at a typical grad math course. They love artin. artin is full of proofs. Well, show me how the direct product works out. Ok, install GAP, & bang out some 10 line script, & boom, done! No refactoring, no nice variable names, no explanation...its as opaque as it gets. You just call the function & it'll do its thing. You want to know why ? Well, that's programming, & we are mathematicians, why do you want to know those things, its some messy bullshit C code, they have this thing called data structure in programming, you have to know about pointer, reference,...dude just type the script & get back to Artin. So each culture actively repels the other, even though they are massively co-dependent. Even department level politics are driven by that rivalry. Math depts are money losers net net. CS otoh brings in tons of dough. Guess who teaches all the difficult discrete math courses in CS ? Yeah, its the math profs! Crazy, I tell you.
EvanMiller 14y ago
> if you don't do proofs you won't get any better at understanding mathematics There is a vast world of mathematical understanding available to programmers who don't like proofs. I think there is some miscommunication here about what constitutes mathematics. Mathematicians tend to think of the art of proving things, whereas engineers (and programmers, and scientists) think of equations and how to solve them. I think mathematicians actually do a disservice to engineers by trying to beat them over the head with real analysis and set theory (which is why most physics and engineering departments end up having to teach their own mathematical methods courses). The "foundational" knowledge of mathematics -- epsilons, deltas, Cantor sets, Banach spaces, etc. -- is irrelevant to almost all practitioners. Newton, Taylor, Euler, Gauss, Laplace, Bessel, Maxwell and the gang got pretty far without it. When programmers say they want to learn math, they mean they want practical knowledge: interesting functions, how to compute them, and their properties that can be applied with utility. They don't want -- or need -- to spend time poring over proofs.
- j2kun 14y ago
  It seems you're under the impression that real analysis is the foundation of mathematics (I certainly wouldn't consider Cantor sets or Banach spaces in there). Let's say you invent a new machine learning algorithm, how can you know how well it does? If you invent an algorithm to do anything, how can you be sure it's correct? Well you can always test it some things, but if it's really a new algorithm, then you need to prove it does what you say it does in all possible cases. It's fine and dandy if someone tells you that there is this function that you can compute and use in this way and it's the best for its purpose, but this is an extremely rare case. I believe I have mentioned this elsewhere in comments, but there is almost never a clear-cut answer in mathematics that someone can just use out of the box. It almost always involves tweaking to fit a particular application, and to really understand how to tweak an algorithm you need to understand why the algorithm works the way it does.
  - jholman 14y ago
    I agree with you that if you want to prove the correctness of a new algorithm, you need to prove the correctness of that new algorithm. You're gonna want some proving skills there. How often are programmers developing new algorithms? I guess it depends on where you draw the line for "algorithm", but let me propose two possible places for the line. On the one hand, you might use existing techniques in a new function. In this case, the proving technique you need is the theory of invariants and so on, as Dijkstra ranted about. You're not gonna need a lot of practice with higher-level math proofs for that. That's even assuming you care about "proving that it does what you say it does in all possible cases", which of course we all know is done by roughly 0% of programmers, especially with emphasis on the "in all possible". On the other hand, you might make a bigger development, that requires more mathematical expertise. I suggest for your consideration that the correct description of a person doing this latter work is not "programmer", but "professor" (or grad student), and that this is relatively rare, and if this is what you meant all along, you've been using misleading language. I think you have it absolutely backwards when you say "this is an extremely rare case"; I think the case where you need real mathematical proof techniques is the extremely rare case, even in relatively math-heavy areas, e.g. numeric simulation. What you need, as I've said before, are techniques of calculation. Also, my ML knowledge is weak, but from my modest knowledge, I don't think any of it works provably. It works probably. :) Seems a weird example to choose. At this point, btw, I acknowledge that I'm thoroughly into "quibble" territory. =]
jholman 14y ago
I suggest that your point is that if you want to be a better mathematician, you need to get comfortable with proofs. Sure, well, so what? If a programmer tells you they're interested in math, and they don't want to learn proofs, it's possible that they're saying the ludicrous thing that your article claims they're saying... but it's more likely that they're saying "I want to use the calculating techniques of math". Speaking for myself, I have a very modest interest in getting better at proving, but significant interest in getting better at calculating. As for the for-loop, the reasons may be wacky (wackier, I admit, than interpreting for(;1;); ), but there's something fundamentally different between the for-loop and the summation. In the for-loop case, everything you need to know to interpret that code is written down in an obvious place.

by j2kun 14y ago

dxbydt 14y ago

>you need to get comfortable with proofs True, but this is simply not the point of programming/CS. Back in grad school in CS, we used leiserson. Leiserson has proof of quicksort! I mean, that's fucking crazy. He mathematically derives amortized runtime of quicksort.I really loved leiserson. But even my professors hated it...they'd say, lets skip over the proof section, its not important. Nowadays people use Skeina. Skeina is like a storybook. It tells you - do this, get that, if you want to know more, read leiserson! So skeina basically punts. This is why everybody loves skeina, because no proofs. Just straight algorithms that can be translated to code. Skeina is slightly better than Numerical Recipes cookbook, in that it tells you what to do & points you to the why, but doesn't tell you the why. But math is all about why. Now look at a typical grad math course. They love artin. artin is full of proofs. Well, show me how the direct product works out. Ok, install GAP, & bang out some 10 line script, & boom, done! No refactoring, no nice variable names, no explanation...its as opaque as it gets. You just call the function & it'll do its thing. You want to know why ? Well, that's programming, & we are mathematicians, why do you want to know those things, its some messy bullshit C code, they have this thing called data structure in programming, you have to know about pointer, reference,...dude just type the script & get back to Artin. So each culture actively repels the other, even though they are massively co-dependent. Even department level politics are driven by that rivalry. Math depts are money losers net net. CS otoh brings in tons of dough. Guess who teaches all the difficult discrete math courses in CS ? Yeah, its the math profs! Crazy, I tell you.

EvanMiller 14y ago

> if you don't do proofs you won't get any better at understanding mathematics There is a vast world of mathematical understanding available to programmers who don't like proofs. I think there is some miscommunication here about what constitutes mathematics. Mathematicians tend to think of the art of proving things, whereas engineers (and programmers, and scientists) think of equations and how to solve them. I think mathematicians actually do a disservice to engineers by trying to beat them over the head with real analysis and set theory (which is why most physics and engineering departments end up having to teach their own mathematical methods courses). The "foundational" knowledge of mathematics -- epsilons, deltas, Cantor sets, Banach spaces, etc. -- is irrelevant to almost all practitioners. Newton, Taylor, Euler, Gauss, Laplace, Bessel, Maxwell and the gang got pretty far without it. When programmers say they want to learn math, they mean they want practical knowledge: interesting functions, how to compute them, and their properties that can be applied with utility. They don't want -- or need -- to spend time poring over proofs.

j2kun 14y ago
It seems you're under the impression that real analysis is the foundation of mathematics (I certainly wouldn't consider Cantor sets or Banach spaces in there). Let's say you invent a new machine learning algorithm, how can you know how well it does? If you invent an algorithm to do anything, how can you be sure it's correct? Well you can always test it some things, but if it's really a new algorithm, then you need to prove it does what you say it does in all possible cases. It's fine and dandy if someone tells you that there is this function that you can compute and use in this way and it's the best for its purpose, but this is an extremely rare case. I believe I have mentioned this elsewhere in comments, but there is almost never a clear-cut answer in mathematics that someone can just use out of the box. It almost always involves tweaking to fit a particular application, and to really understand how to tweak an algorithm you need to understand why the algorithm works the way it does.
- jholman 14y ago
  I agree with you that if you want to prove the correctness of a new algorithm, you need to prove the correctness of that new algorithm. You're gonna want some proving skills there. How often are programmers developing new algorithms? I guess it depends on where you draw the line for "algorithm", but let me propose two possible places for the line. On the one hand, you might use existing techniques in a new function. In this case, the proving technique you need is the theory of invariants and so on, as Dijkstra ranted about. You're not gonna need a lot of practice with higher-level math proofs for that. That's even assuming you care about "proving that it does what you say it does in all possible cases", which of course we all know is done by roughly 0% of programmers, especially with emphasis on the "in all possible". On the other hand, you might make a bigger development, that requires more mathematical expertise. I suggest for your consideration that the correct description of a person doing this latter work is not "programmer", but "professor" (or grad student), and that this is relatively rare, and if this is what you meant all along, you've been using misleading language. I think you have it absolutely backwards when you say "this is an extremely rare case"; I think the case where you need real mathematical proof techniques is the extremely rare case, even in relatively math-heavy areas, e.g. numeric simulation. What you need, as I've said before, are techniques of calculation. Also, my ML knowledge is weak, but from my modest knowledge, I don't think any of it works provably. It works probably. :) Seems a weird example to choose. At this point, btw, I acknowledge that I'm thoroughly into "quibble" territory. =]

jholman 14y ago

I suggest that your point is that if you want to be a better mathematician, you need to get comfortable with proofs. Sure, well, so what? If a programmer tells you they're interested in math, and they don't want to learn proofs, it's possible that they're saying the ludicrous thing that your article claims they're saying... but it's more likely that they're saying "I want to use the calculating techniques of math". Speaking for myself, I have a very modest interest in getting better at proving, but significant interest in getting better at calculating. As for the for-loop, the reasons may be wacky (wackier, I admit, than interpreting for(;1;); ), but there's something fundamentally different between the for-loop and the summation. In the for-loop case, everything you need to know to interpret that code is written down in an obvious place.