Question

Are there any serious scientific math libraries made with functional programming languages? From the very nature of functional languages one would think that they are particularly suitable for math, but yet the well-known algorithms seem to be procedural.

For instance, the classic Numerical Recipes series is written pretty much in procedural way. LAPACK is almost de facto standard in many fields, but it’s in Fortran and thus procedural or maybe OO, but definitely not functional.

Has anyone been able to transfer these kinds of well-known procedural algorithms to functional style?

Update: it seems to be so that functional languages are being used in symbolic calculations, e.g. in Mathematica. But, is there something inherently incompatible with numeric calculations and functional algorithms? Or is it just so that because imperative algorithms happened to be invented first, nobody has bothered to come up with functional equivalents?

Answer 1

There’s a Haskell library for numerical stuff in hackageDB: hmatrix. It draws from LAPACK, BLAS and GSL (GNU Scientific Library).

But you should keep in mind that imperative algorithms can be readily transferred into purely-functional languages using monads (more specifically, state transformers). In fact, any efficient, in-place implementation must generally use such a mechanism to provide mutable variables in purely-functional languages.

As for following a functional style, it isn’t possible in many cases. For many problems, there aren’t any (efficient) functional approaches known. Of course, you can get such algorithms to work in Haskell for example, but they won’t look much different than if they were written in Matlab, Fortran or C.

EDIT:

It’s both an apparent incompatibility, as well as an issue of which came first:

1. Efficient numerical algorithms usually require mutable data. While this is possible in a purely-functional setting, it is not as straightforward as in imperative languages. But the two computational models are perfectly equivalent.
2. The underlying machine (e.g. instruction set) has always been and still is imperative, with very few exceptions (!). Imperatively-coded algorithms are easier to analyze and optimize given the way the real machine is modeled.
3. While the underlying mathematics allow relatively easy derivations for functional solutions, you won’t get an efficient algorithm (just as in the case of deriving imperative solutions directly from mathematics). Since most effort has been and still is directed towards imperative solutions, functional counterparts are simply unknown. By functional counterparts I mean code that properly expresses functional intent and style.
4. There’s quite a lot of imperative code that can be reused. Much of it can be transcribed into a functional language using state transformers, though it would still look imperative.

I actually think a purely-functional language like Haskell could be beneficial for coding algorithms: one could unify the mathematical description, the algorithm itself and some sort of type-oriented proof (i.e. using the Curry-Howard isomorphism) in the same chunk of code.