Functional programming for scientific computing

With the increasing importance of parallel computers, ranging from multi-core desktop machines to massively parallel machines such as IBM’s BlueGene, functional programming could well become an important technique for scientific software development, as it facilitates program transformations (including those for automatic or semi-automatic parallelization) considerably. It also appeals to the mathematical bend of many scientists in making it possible to apply mathematical reasoning to computer programs. The downside: there is a steep learning curve for those familiar with traditional programming (called “imperative”).

I have written an introduction to functional programming for scientists for the July issue of Computing in Science and Engineering. It is also available (free access) via IEEE’s Computing Now portal: http://www2.computer.org/portal/web/computingnow/0609/whatsnew/cise

While I don’t expect functional programming to be adopted rapidly by computational scientists, I am convinced that ten years from now, it will be an essential item in everyone’s toolbox. Better start preparing yourself now!

Explore posts in the same categories: Programming

5 Comments on “Functional programming for scientific computing”

  1. Denis Bzowy Says:

    Konrad,
    nice article — Zukunftsmusik (in a positive sense).

    Do you see any convergence in the triangle
    numpy
    Sun’s Fortress
    Clojure / Haskell
    within the next year or so ?

    Let’s call a hypothetical little language “Fumpy”:
    in: vectors, matrices, ndarrays, ufuncs ~ numpy.numeric
    syntax: ?
    out: numpy text.
    This hardly defines it, but it would be nice if it had
    – a small set of axioms / an algebra
    – programs as manipulable trees
    – speedup transforms, under some cost model, on those trees.

    Are there projects along these lines on islands around Python/numpy ?

    “If I had asked people what they wanted, they would have said faster horses.”
    –Henry Ford

    • khinsen Says:

      Within a year, no, I think that’s too short. Within five years, yes, that’s a possibility. It all depends if some community will develop around these ideas that will do the required work. At the moment, I see signs of interest, but little willingness to invest real effort into such a project.

      My own attempt at investigating these issues is the multiarray design study for Clojure. I’d like to keep the name “design study” for a while, as the implementation is not really my main concern for the moment.

      A big problem in my opinion is interfacing to existing code. There is a huge amount of good scientific libraries based on NumPy, all of which lives in the C/Fortran world and is interfaced specifically to Python.

  2. Pat Says:

    Konrad,
    I’ve been coming to much the same conclusion — functional programming is a far better paradigm for scientists/engineers than than imperative. I’ve been playing with my version of “multiarrays” in Racket (like Clojure, a derivative of Scheme, itself a derivative of Lisp).
    Racket has a fairly good C interface. I’m not aware of any Fortran interface work.
    The “existing code” problem is a big one — I have no doubt that I’m reinventing the wheel with some of my current efforts, but what do you live with? Clunky legacy imperative interfaces, or buggy new functional interfaces?
    In the long run, functional programming will win. Based on the timing of replies to your post, I hesitate to put a target date on that prediction :)

    • khinsen Says:

      Good luck with your Racket project! Personally I have looked at Scheme and decided it was not for me, because of the highly fractioned community. Hardly any serious code works with more than one Scheme implementation. But otherwise, Scheme has much to like, and Racket is a very impressive Scheme implementation.

      Concerning the future of functional programming in science, I think the most promising way to get there (as a community) is slowly, by adopting more and more of a functional approach even in the non-functional languages we use today. Well, perhaps not Fortran or C, but definitely Python.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: