6 ms·

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

• 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.
        • 12y ago
  • 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