After a year of writing this blog, what have I learned about the nature of the relationship between computer programs and mathematics? Here are a few notes that sum up my thoughts, roughly in order of how strongly I agree with them. I’d love to hear your thoughts in the comments.
- Programming is absolutely great for exploring questions and automating tasks. Mathematics is absolutely great for distilling the soul of a problem.
- Programming is fueled by the excitement of what can be done. Mathematics is fueled by the excitement of how things relate, and why they relate.
- Good mathematics makes for short programs.
- Good mathematics can be sloppy. Good programs cannot.
- Useful algorithms can come from any branch of mathematics, so it is best to be familiar with them all (at least a little).
- Most programs written for the real world use no mathematics beyond the level of an average twelve-year-old, but every program indirectly relies on sophisticated mathematics in an essential way.
- Programs that are fun, exciting, or generative invariably utilize some branch of mathematics.
- Short programs that do mathematical things are prohibitively mystical until you’ve spent weeks on the mathematical background. Once those weeks are spent, everything is so obvious it’s trivial.
- The hard question in software design is: how can we take this to extremes? The easy, natural question in mathematics is often: what happens when we take this to extremes?
- Abstraction in a program is strikingly similar to abstraction in mathematics, but the former takes a lot of work while the latter is instantaneous.
Couldn’t agree more with #10 (especially after working on a polynomial space library)!
Reblogged this on Guzman's Mathematics Weblog and commented:
A post from one of the blogs I follow, which happens to combine my love of mathematics and programming. Check it out! 🙂
Thanks a lot! 🙂
No 3 should be 1!…nice article though.
I didn’t put them strictly in order of which is most important, but more that the items at the end required more refinement after my first draft of this list, while the first five or so items were immediately obvious to me, and remained unchanged from the moment I wrote them.
I think you have #4 backwards.
“Beauty is the first test: there is no permanent place in the world for ugly mathematics.” — G. H. Hardy
Sloppiness is not equivalent to ugliness. They mean two very different things. Sloppiness in mathematics is liberally applied, rigorously controlled, and can still result in beautiful proofs, while overly pedantic math can be extremely ugly and tedious. A program which is sloppy simply will not work. That’s what I meant.
For instance, in almost every branch of mathematics there is a pervasive sloppiness in identifying the image of an injective function with the domain of the function. Even more so, in topology there is almost never an explicit computation of a homeomorphism; mathematicians instead rely solely on the intuition of what kinds of operations are allowed during homeomorphisms, and they draw pictures to describe them. In programming, the biggest amount of allowable sloppiness is in type conversions a la Python’s duck typing (or type promotions, say, in C). And even that’s not really that sloppy, because there are rigorously defined underlying rules that any expert must know religiously.
“programs written for the real world use no mathematics beyond the level of an average twelve-year-old”
Are point 1 and point 9 contradicting? I can’t recall a program which is exploring by nature, they always tend to converge. But mathematics has this magic of both converging and wonderfully exploring, I feel.
I am loving your work and appreciate your efforts to share it with the world!
For 1. I meant it as if one doesn’t know how to approach a problem, a really great option is to write a program (or a number of small programs) to explore it. I’m actually doing this now in a bit of research with a professor of cognitive psychology, and if it goes well I’ll certainly present it here on my blog.
For 9., however, I meant that in software taking something to extremes means applying an algorithm to large data sets or user bases. That’s often when the problem becomes balancing time versus space efficiency, among other concerns. These problems have no best answers. On the other hand, if you want to make a mathematical idea larger (say you want to extend some notion from finite dimensional linear algebra to general Hilbert spaces), often times you can just do it without thinking twice! And such questions arise all the time.
And I’m certainly not listing all of the virtues of math and programming here, just the things I feel to have learned most over the past year of working on this blog.