Last Friday I posted on @SciPyTip a summary of why I like SciPy, the scientific programming library for Python.
I’d rather do math in a general-purpose language than try to do general-purpose programming in a math language.
Mathematical software is never purely mathematical. The math has to connect to something, and that’s where most of the programming effort may go.
If you’re responsible for the math and for the larger system it’s embedded in, you have three options.
- Write the math in an application programming language.
- Do application programming in a mathematical language.
- Use different languages for the math and the larger system.
My preferred option is #1. My second choice is #3. My last choice, by far, is #2.
Application languages are typically better for math than mathematical languages are for applications. Application languages also have a larger user base, and hence better documentation and tools.
Mixing two languages works well in a team that has someone specialized in the math language, someone specialized in the application language, and someone fluent in plumbing the two languages together. If you have be all three people, you might wonder whether you could do everything in one language.
#3 may also make a lot of sense when you’re really choosing a numerically fast language, not a math language per se. It may be well worth writing that inner loop that feeds your numerical solver in C or C++ even while most of your application logic is written in something less cumbersome.
I really do like this post, since it really offers good advice. I’ve worked with MATLAB and Maple to do mathematical tasks, and the “general” programming element in those tools exist but are severely lacking. Meanwhile, using C for even moderately complicated mathematical tasks can actually be pretty straightforward AND produce re-usable software.
Great thoughts. I recently had an interesting conversation with several electrical/computer engineering professors. We were talking about programming proficiency and their biggest gripe was how (a) grad students generally can’t program and (b) those with some ability tend to treat Matlab as if it was C++, trying to accomplish things far outside the language’s intended use.
Since I generally only use general purposes languages like C++ and most recently C#, I have to do most math oriented programming in those languages. The thing I like about using the general purpose languages, particularly C++ is that the compiler optimizers and availability of optimized libraries can make up for a lot of the advantages of the math oriented languages, particularly for production jobs that must run day in and day out and be reliable.
This is a good point. I don’t do any mathematical computation (well, all computation is mathematical, but you know what I mean), but I will keep this in mind if I ever need to. Have you looked at Julia (http://julialang.org) yet? What are your thoughts there?
-Matt
I don’t have recent experience of this, but in the early 80s I worked on a project like this and I agree with your choices. Doing the file handling in Fortran was not an option. Doing the maths in Cobol was an option, as it we were doing everything on an ICL computer with ICL-supplied compilers. The Fortran maths library was available to Cobol users and ICL’s implementation of Cobol’s COMP1 (single precision floating point) and COMP2 (double precision floating point) were identical to their implementation of Fortran’s REAL and DOUBLE PRECISION. We ended up with a mixed Fortran and Cobol solution and it all went well. The key was that everything came from one vendor.
I always choose #3 for anything serious. #1 is just too inefficient, you’ll just be unsatisfied creating simple things like matrix multiplication routines when you know it’s been done before. Right now I’m writing code to strip data from the NIST ALS web site and put it into a flat file, and that’s in Ruby. But I’d shoot myself trying to create pretty spectra from the data in Ruby, instead I move to Octave.
Ages ago I worked only in FORTRAN and C. Then Ruby blew my mind with its string processing abilities, I can actually write a parser for something complex in just hours. The only thing mathematically “cool” about Ruby, as far as I’m concerned, is Bignum. Octave, PAW, gnuplot and other math -> graphics languages excel for producing clean code which efficiently handles large amounts of calculations and visualizations.
Writing this “plumbing” code is trivial between Octave and Ruby. Merely go to Octave and dump an array into a file. Upon inspection, you’ll see that writing a class to read and write that file is trivial in Ruby, might take 15 minutes.
John: Python is efficient enough for me. The SciPy library is mostly implemented in C and Fortran, so the function calls are fast as long as you give it a large amount of work at a time. Matrix calculations, for example, are done in LAPACK. You do have to change the way you code a bit, but if you use vectorized operations etc your code can be fast.
There is an interesting and related thread happening on CrossValidated regarding the Julia language. The R proponents seem to feel that R’s popularity will be difficult to overtake. I linked to this post, agreeing with it. I try to do most everything in Python and use R for very specific needs (like its excellent time series packages), and a lot of that is because I can stay in one language for so long. See http://stats.stackexchange.com/questions/25672/does-julia-have-any-hope-of-sticking-in-the-statistical-community