Math Code: Sunday, February 13, 2005

Math coding is the writing of software to implement a piece of mathematics.

Being extremely fond of writing software but not being dependent on it for a living makes it truly enjoyable. Every now and then I find myself the victim of bad design, always self-inflicted. Like recently, I wrote a piece of code for posting the solution to a homework problem, and did a pretty hasty hack job, so much so that while still being a pretty nice piece of programming, it lacked the clean, readable form that tells you instantly when it is done, and done well. And for that reason, more than any other, it had a bug, and maybe more. I have still to debug this, and will do so I know. But its hard to go back and fix something that does not deserve it. Trash is trash, who wants to take it from bad trash to good trash?

Good code (especially that with a mathematical purpose) needs to be short. It should be as readable as the underlying mathematics. Really good implementation code is so good that reading it is sufficient, you do not need to read the math; superb code is even better - after reading it, it improves your understanding of the math.

How do you write good code that implements mathematics? So good that you need almost no comments? There is but one way, in my opinion, make it really concise. This will also make the code simple and efficient. Take everything out that is superfluous. Here is a quote, which is spot on, simple and elegant: "A designer knows that he has achieved the perfect design not when there is nothing left to add, but when there is nothing left to take away" - Antoine de St-Expurey.

Here are some rules that I have learnt from experience over the years.

1. Math code can be very different in different languages. Choose the language well. The good news is that you do not need to know many languages well to choose one, and the bad news is that some languages are much better than others. Some like Perl, are not meant for math code, its syntax makes it hard to later revisit the math. Python is much better but is also not really suited for this. C and Java are pretty good. But best are packages like Matlab, Octave, Mathematica that have grown into full-blown programming languages. I find VBA programming in Excel very conducive to writing good math code- using the macro interfaced with spreadsheet offers tricks and hacks (all elegant) that are unavailable in other environments.

2. You can write really good math code without knowing heaps of features of the chosen language. Writing good math code is a matter of style, not that of the richness of language features. I hardly know a lot of language features, and tend to find them when needed. That is why I enjoy reading student written code - there is always something in the programming language that I am introduced to.

3. Develop a personal style. It is really important when writing math code. I have one, and I know it, it suits me well. It took me a long time to feel it. I am afraid I cannot tell you how to do this, its personal. All I know is you will not find it by looking over someone else's shoulder. Just write a lot of code, and if you are not enjoying it, then your style is off. You will know when the style fits.

4. Keep trashing the code until it looks good. Its got to be pretty. Don't get locked into the first version you write, ending up with some variant of your initial draft. This sounds like the same advice given to young writers of prose, and in many ways, yes, it is the same thing. But math code is different - if you buy into to the idea of keeping it short, your final product is about 1-2 pages of code. With that in mind, it is not in the least bit painful throwing it away and starting again. Do this often, and soon, you find your first versions are pretty good already. Once it feels good, go back and take out all the unnecessary stuff. The usual programming instinct is to tidy up by adding comments. Good math code does not need it. Whoever wants to read it needs to know the math anyway, and if you write it clean and neat (and concise) it will be easy to read. Math is truth, and truths are meant to be self-evident.

5. If the code is unwieldy, runs slow, is hard to read, and fails to improve after a few writing iterations, there is something wrong with the math or the numerical recipe you came up with. Many times, in sheer frustration, or from absolute need, I have had to go back and revisit the math, and lo and behold, there pops up a terrific new way of defaling with the whole problem. Work it out nicely, reprogram and voila, it works great. Never be reticent about revisiting your mathematical analysis. I am never happy with my theoretical work until I have the model coded and running, running really well. Often running well in two separate languages. Good math works well. Write once, run anywhere.

There is something special about writing code to implement math. Its a different mind set, a varied skill, and not easy to develop. Most mathematicians will never be good at it, despite knowing the math well, which seems like it must be a major prerequisite. Physicists are great at it. So there is something about training. Engineers should be, but are most often not good at it. There is an essential attitude - something about trying to mimic the real world in software that makes for writing good code, and that is something physicists do well. So do people with computer-science degrees. And some in Applied Math.

What I like about math coding is that I always deeply enhance my understanding of the math through the process of programming it. Its like a wheel of understanding, it comes round to feed itself through the code. Most of all, it enhances my passion for the math to see it really work.