In the past few weeks I have started work on a major software development effort. It is a very complex bit of software for capturing images from high-performance cameras and reducing them mathematically to functions used in high-end digital rendering. The process is very complicated mathematically and computationally intense, in some cases requiring as much as eight hours of processing.

One of the first questions I wrestled with was which language to use for the development. I was surprised at the answer.

I started my career in IT more than 30 years ago developing mathematical code for scientific applications, and as I sat down to make the decision I felt like I was in a time warp. When I was growing up, savings accounts were common. You made small deposits which were recorded in ink in a small paper book about the size of passport. Over time the pass book took on a comfortable worn look that was a source of pride, reminding you of your thrift, as my worn passport reminds me fondly of my travels. Once a quarter the bank totaled your balance and added a bit of interest. The rates were terrible, — 2 or 3 percent at best, but were made worse because of the infrequent compounding. One reason banks didn’t compound interest often was that the market didn’t demand it, but another reason was that it wasn’t easy to do. The rudimentary computing equipment and software of the time meant the interest was literally added to an account with an “interest” program that took hours to run for all of the bank’s many accounts.

The biggest bank in town was innovative and moved quickly to automate with Burroughs banking equipment, and with their added computing power began to offer some impressive new services. The early investment in high-end computers paid off, and the bank eventually grew into a major service provider to other banks, and provided me with my first professional IT job. The immediate application of the technology, though, was to provide current (daily) account information to multiple branches in the form of huge, green-bar reports, to print deposits in the bank books rather than writing by hand (wow, did that look high-tech) and, my favorite part, to compound interest every month.

They advertised this widely, with a cheesy jingle typical of the era. My father was good friends with the executives of the competing bank (which was literally across the street) and they took the escalation seriously. They responded by buying the latest and greatest from IBM (a 1620) and after a few intense months, proudly announced weekly compounding. The war escalated, and Burroughs crowd announced daily compounding. The IBM camp then launched the nuclear option – continuous compounding. The executives from the Burroughs bank stepped up and said “Oh, yeah, we can do that too”.

Oops – there’s a problem. Continuous compounding is done in a completely different way from periodic compounding. In the old days you ran an interest program – once a quarter, month, or whatever. As the interest rate war progressed the banks just bought newer, bigger, faster computers so that they could run the program more quickly. With continuous compounding, however, you only calculated the interest when there was an event – a deposit, withdrawal or statement, and then you had to do exponentiation. Unfortunately, the Burroughs COBOL of the day did not have a built-in function for exponentiation.

That omission got me my first professional gig. The bank came to the local college and asked for someone who could write code to implement this one function. I got the task and dispatched it in short order. I wrote it in Burroughs Algorithmic Language (which hasn’t been seen in the wild since 1977 and is presumed extinct).

So how have things changed? My recent experience suggests that things might not have changed as much as I thought. First, in recruiting for coders, I found that there were a huge number of people who were skilled at building web and data applications, but the folks who know how to make machines do math fast are rare birds, indeed, just as it was 35 years ago.

This didn’t surprise me too much, as the market for business applications is vastly larger than the market for scientific applications. What did surprise me, was the way the old languages are still competitive. The test I devised was to write an equation solver (using the Newton Raphson method) in several languages and trying several different compilers. I constructed a problem where the root was exactly pi, so I could check the answer against published values to very high precision.

I tested Fortran, C, C#, and J# . The results were completely clear – the object oriented languages were crushed. The simple old procedural languages really are faster for the mathematical heavy lifting. It was close between the two C compliers I tried and the three Fortran’s, but the Intel Fortran compiler seems to be king of the hill. It was fast, and the results were spot on to 32 decimal places.

It may not be sexy or look very modern, but if you have to do serious math on 16 mega pixel images, plain old Fortran is still the way to go. Certainly the vast bulk of the new company’s code is going to be written in something more current – their web site, e-commerce site, and internal system, for example, but the hard core, the nut that will make or break the company is going to be in Fortran. Now I’m back where my bank employers were in 1970 – looking for some math stud at the local college.

Technorati Tags: software security, banking, Fortran

This entry was posted by Craig Miller on Tuesday, September 18th, 2007 and is filed under Software Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.