6 ms·

I've always wondered why computational mathematicians/physicists end up using MATLAB/FORTRAN instead of haskell or similar.

jbooth 12y ago
Because they're trying to do work with computers, rather than do research about computing. If the interestingness of the implementation doesn't matter and you just want results, go with MATLAB/FORTRAN/Numpy or whatever and a fast BLAS implementation. Mutable state everywhere, side effects everywhere, you got your results fast and can go finish your paper or your project or whatever.
- warfangle 12y ago
  Yeah, but with Haskell the code would look more like the actual equations you're working from and not an implementation of the equations (thinking like differential manifolds etc).
  - sampo 12y ago
    How does matrix indexing look like in Haskell?
    - codygman 12y ago
      I found this by looking at the repa docs: mmMult :: Monad m => Array U DIM2 Double -> Array U DIM2 Double -> m (Array U DIM2 Double) mmMult a b = sumP (Repa.zipWith (*) aRepl bRepl) where t = transpose2D b aRepl = extend (Z :.All :.colsB :.All) a bRepl = extend (Z :.rowsA :.All :.All) t (Z :.colsA :.rowsA) = extent a (Z :.colsB :.rowsB) = extent b http://www.haskell.org/haskellwiki/Numeric_Haskell:_A_Repa_Tutorial#Example:_matrix-matrix_multiplication http://www.haskell.org/haskellwiki/Numeric_Haskell:_A_Repa_T...
      - sampo 12y ago
        I meant, just accessing a matrix element i,j which in many languages happens by m(i,j) or m[i,j].
        hollerith 12y ago
        The literal answer to your question is readIOArray m (i,j) But that is misleading because there are two kinds of arrays in Haskell, and the kind (namely, mutable) I used in my literal answer is the less common kind. In fact, it is so uncommon and so contrary to the spirit of Haskell that the language implementations do not take the trouble to make it fast. Last time I played with the Glasgow Haskell Compiler, for example, a related operation (readIORef) was over 100 times slower than its counterpart in C. Parenthetically, because you need to use "a monad" to perform any sort of mutable operation in Haskell, the translation of m[i,j] := m[j,i] into Haskell is not writeIOArray m (i,j) (readIOArray m (j,i)) like someone unfamiliar with monadic style might think, but rather readIOArray m (j,i) >>= writeIOArray m (i,j) or equivalently do element <- readIOArray m (j,i) writeIOArray m (i,j) element But that is a side issue. The central fact is that even though it is technically possible, it is considered bad style in Haskell to access or update individual array elements.
        cabinpark 12y ago
        > The central fact is that even though it is technically possible, it is considered bad style in Haskell to access or update individual array elements. And another reason why Haskell will not fair well. A lot of numerical mathematics is linear algebra which involves, almost exclusively, updating array elements. I'm sure Haskell is good at some things but for many of the types of problems that numerical analysts face Haskell's paradigm just doesn't make sense. Especially when we have languages like Fortran/Matlab which were explicitly designed for computational mathematics.
        sampo 12y ago
        Yeah, I was just thinking that as /u/warfangle/ said that > with Haskell the code would look more like the actual equations you're working from so at least in matrix algorithms, and finite difference methods for partial differential equations, the textbooks usually explain the algorithms using a notation that refers to matrix elements. So in these cases, an imperative implementation would be close to the math textbook representation, and the Haskell code would not.
  - cabinpark 12y ago
    What does this mean? I've seen this before and I don't get what it means. Look more like the actual equations? Can you give me a concrete example of Haskell code that solves a simple PDE?
- ixmatus 12y ago
  Once you've learned Haskell, actually, you can be far more productive in it than most other languages. The only piece of your statement that I'll agree with is that Haskell doesn't really have any great numerical or scientific tooling (like Python). As languages go, Haskell out paces (not just in elegance but pragmatism too) most of the mainstream imperative languages. The tooling for scientific computing does need to catch up though.
  - tormeh 12y ago
    Can the typechecker ensure that your matrices (constructed from files) have compatible dimensions to be multiplied together? No? None of the compilers I've tried are much good for numeric computing. Since the error-prone parts of writing your code are not made easier by the typechecker, a dynamic language works just as well and has much lower cognitive overhead. Remember that scientists don't care about the quality of their code. In many cases, once the code is complete, it will only run once and then be thrown away. There is no maintenance. Things like technical debt don't exist. And pragmatism? Haskell doesn't even have loops. Loops with mutable variables inside are a very intuitive way of thinking about things and often a better fit to a problem than recursion. Sure, you can use tail recursion (which is just ugly looping) instead, but you're adding unwanted cognitive overhead. What I would like is a functional language with enclosed, sealed off loops. Syntactic sugar for tail recursion, basically, but Haskell isn't built with programmers in mind; it's built for CS researchers. Computer language researchers, more specifically.
    - codygman 12y ago
      I believe you could enforce something like compatible dimensions in Haskell in a library, but I could be wrong. If not, I wonder if you could do it in idris.
      - Ixiaus 12y ago
        Idris is a wonderful language but the tooling there is even more immature for numerical computing than Haskell.
    - 12y ago
dimitar 12y ago
Matlab toolboxes and Fortran libraries.
Dewie 12y ago
Well... modern Fortran has pure procedures, at the least.
leephillips 12y ago
The author of the article gives a hint: "Haskell isn't very good at dealing with arrays." High performance numerical code typically involves mutating large arrays distributed over a grid of machines or processors. I talk about the question you ask a little more here: http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/ http://arstechnica.com/science/2014/05/scientific-computings...
- deleted 12y ago
  [deleted]
  - deleted 12y ago
    [deleted]
    - deleted 12y ago
      [deleted]
- nightski 12y ago
  That just isn't true though. It might be true for the standard prelude, but there are very high performance options available. Not only that, there are great wrappers to the standard C/Fortran scientific libraries used by everyone. I have written real time 3D reconstruction and SLAM algorithms in Haskell, so I have had to face this head on.
micro_cam 12y ago
I one who tried it but ended up having to port to python to use a sparse linear system solver. The state of the art in numerical computing really isn't to the point we can work from equations because things like sparsity and which solver you use (Algebraic Multi Grid? Conjugate Gradient Descent? ...) matter a lot and the established algorithms and implementations are really fast and well tested.
agumonkey 12y ago
FORTRAN = decades of battle tested (also not-understood-so-much-anymore), performant code.

jbooth 12y ago

Because they're trying to do work with computers, rather than do research about computing. If the interestingness of the implementation doesn't matter and you just want results, go with MATLAB/FORTRAN/Numpy or whatever and a fast BLAS implementation. Mutable state everywhere, side effects everywhere, you got your results fast and can go finish your paper or your project or whatever.

warfangle 12y ago
Yeah, but with Haskell the code would look more like the actual equations you're working from and not an implementation of the equations (thinking like differential manifolds etc).
- sampo 12y ago
  How does matrix indexing look like in Haskell?
  - codygman 12y ago
    I found this by looking at the repa docs: mmMult :: Monad m => Array U DIM2 Double -> Array U DIM2 Double -> m (Array U DIM2 Double) mmMult a b = sumP (Repa.zipWith (*) aRepl bRepl) where t = transpose2D b aRepl = extend (Z :.All :.colsB :.All) a bRepl = extend (Z :.rowsA :.All :.All) t (Z :.colsA :.rowsA) = extent a (Z :.colsB :.rowsB) = extent b http://www.haskell.org/haskellwiki/Numeric_Haskell:_A_Repa_Tutorial#Example:_matrix-matrix_multiplication http://www.haskell.org/haskellwiki/Numeric_Haskell:_A_Repa_T...
    - sampo 12y ago
      I meant, just accessing a matrix element i,j which in many languages happens by m(i,j) or m[i,j].
      - hollerith 12y ago
        The literal answer to your question is readIOArray m (i,j) But that is misleading because there are two kinds of arrays in Haskell, and the kind (namely, mutable) I used in my literal answer is the less common kind. In fact, it is so uncommon and so contrary to the spirit of Haskell that the language implementations do not take the trouble to make it fast. Last time I played with the Glasgow Haskell Compiler, for example, a related operation (readIORef) was over 100 times slower than its counterpart in C. Parenthetically, because you need to use "a monad" to perform any sort of mutable operation in Haskell, the translation of m[i,j] := m[j,i] into Haskell is not writeIOArray m (i,j) (readIOArray m (j,i)) like someone unfamiliar with monadic style might think, but rather readIOArray m (j,i) >>= writeIOArray m (i,j) or equivalently do element <- readIOArray m (j,i) writeIOArray m (i,j) element But that is a side issue. The central fact is that even though it is technically possible, it is considered bad style in Haskell to access or update individual array elements.
        cabinpark 12y ago
        > The central fact is that even though it is technically possible, it is considered bad style in Haskell to access or update individual array elements. And another reason why Haskell will not fair well. A lot of numerical mathematics is linear algebra which involves, almost exclusively, updating array elements. I'm sure Haskell is good at some things but for many of the types of problems that numerical analysts face Haskell's paradigm just doesn't make sense. Especially when we have languages like Fortran/Matlab which were explicitly designed for computational mathematics.
        sampo 12y ago
        Yeah, I was just thinking that as /u/warfangle/ said that > with Haskell the code would look more like the actual equations you're working from so at least in matrix algorithms, and finite difference methods for partial differential equations, the textbooks usually explain the algorithms using a notation that refers to matrix elements. So in these cases, an imperative implementation would be close to the math textbook representation, and the Haskell code would not.
- cabinpark 12y ago
  What does this mean? I've seen this before and I don't get what it means. Look more like the actual equations? Can you give me a concrete example of Haskell code that solves a simple PDE?
ixmatus 12y ago
Once you've learned Haskell, actually, you can be far more productive in it than most other languages. The only piece of your statement that I'll agree with is that Haskell doesn't really have any great numerical or scientific tooling (like Python). As languages go, Haskell out paces (not just in elegance but pragmatism too) most of the mainstream imperative languages. The tooling for scientific computing does need to catch up though.
- tormeh 12y ago
  Can the typechecker ensure that your matrices (constructed from files) have compatible dimensions to be multiplied together? No? None of the compilers I've tried are much good for numeric computing. Since the error-prone parts of writing your code are not made easier by the typechecker, a dynamic language works just as well and has much lower cognitive overhead. Remember that scientists don't care about the quality of their code. In many cases, once the code is complete, it will only run once and then be thrown away. There is no maintenance. Things like technical debt don't exist. And pragmatism? Haskell doesn't even have loops. Loops with mutable variables inside are a very intuitive way of thinking about things and often a better fit to a problem than recursion. Sure, you can use tail recursion (which is just ugly looping) instead, but you're adding unwanted cognitive overhead. What I would like is a functional language with enclosed, sealed off loops. Syntactic sugar for tail recursion, basically, but Haskell isn't built with programmers in mind; it's built for CS researchers. Computer language researchers, more specifically.
  - codygman 12y ago
    I believe you could enforce something like compatible dimensions in Haskell in a library, but I could be wrong. If not, I wonder if you could do it in idris.
    - Ixiaus 12y ago
      Idris is a wonderful language but the tooling there is even more immature for numerical computing than Haskell.
  - 12y ago

dimitar 12y ago

Matlab toolboxes and Fortran libraries.

Dewie 12y ago

Well... modern Fortran has pure procedures, at the least.

leephillips 12y ago

The author of the article gives a hint: "Haskell isn't very good at dealing with arrays." High performance numerical code typically involves mutating large arrays distributed over a grid of machines or processors. I talk about the question you ask a little more here: http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/ http://arstechnica.com/science/2014/05/scientific-computings...

deleted 12y ago
[deleted]
- deleted 12y ago
  [deleted]
  - deleted 12y ago
    [deleted]
nightski 12y ago
That just isn't true though. It might be true for the standard prelude, but there are very high performance options available. Not only that, there are great wrappers to the standard C/Fortran scientific libraries used by everyone. I have written real time 3D reconstruction and SLAM algorithms in Haskell, so I have had to face this head on.

micro_cam 12y ago

I one who tried it but ended up having to port to python to use a sparse linear system solver. The state of the art in numerical computing really isn't to the point we can work from equations because things like sparsity and which solver you use (Algebraic Multi Grid? Conjugate Gradient Descent? ...) matter a lot and the established algorithms and implementations are really fast and well tested.

agumonkey 12y ago

FORTRAN = decades of battle tested (also not-understood-so-much-anymore), performant code.