Simon Peyton-Jones: > Lots of people have observed that Haskell might be a good "scripting > language" for numerical computation. In complicated numerical > applications, the program may spend most of its time in (say) matrix > multiply, which constitutes a tiny fraction of the code for the > application. So write the bulk of the application in Haskell (where the > logic is complex but the performance doesn't matter) and then link to a > C or Fortran library to do the small part that is really compute > intensive. ... > You'd need to find a "real" application though. The classical "kernels" > (matrix multiply, inversion etc) are precisely the things you may not > want to do in Haskell.
That's it. With one "grain of salt". It happened to me that I wanted to write some structurally trivial routines for matrix inversion, iterators for ODEs, etc., but I wanted them *polymorphic*. (And, sometimes, lazy: manipulators of power series, asymptotic expansions, some automatic dif- ferentiation stuff, etc.) Then Haskell was a decent tool, and - as Björn Lisper remarks, the hindrance was the lack of integrated tools. Writing a triple loop to invert a matrix instead of having something like `recip` defined within the field of square matrices, and implemented with some efficiency considerations in mind, is a bit clumsy. Björn quotes and comments: > >The classical "kernels" [...] you may not want to do in Haskell. > > With the current compiler technology for Haskell, one would add. I don't > think it would be impossible to compile such Haskell programs into efficient > code. Functional languages for matrix/array computing was a quite active > research area 10-15 years ago, with efforts like Sisal and Id. These > languages were strict and first order, but you can write such programs in > Haskell. I think it would be possible to have a Haskell compiler that could > manage a subset of Haskell matrix programs quite well. Steven Bevan wrote interesting numeric routines a long time ago. Thorsten Zoerner wrote a Clean package Class with several Lin. Algebra and some "slicing" utilities, which emulated the "vectorized" approach of Matlab. This can be in its greater part translated into Haskell. --- But, please, some criticisms of Matlab are weakly justified. BL says: > Also, MATLAB is very ill-suited to > expressing block-recursive matrix algorithms, which are becoming > increasingly important in numerical computing. And, of course, there is no > decent type system, no higher order functions, etc... Block recursive Schemes in Matlab are easier than in C++. Implementing pyramid algorithms is not difficult. Slicing, reshaping, cloning, etc. of matrices are very powerful tools, but they are so imperative, that it is not easy to see how to replace them with something "functionally purified". The Matlab type system is dynamic and "indecent", but you have objects and inheritance, and you *HAVE* higher-order functions as well. All the Matlab GUI tools, very powerful and reconfigurable are based on objects, which accept callbacks as parameters. This is not so clean as we would like to have, but pragmatically OK. What bothers me a bit in our Haskell world is the fact that the efforts are atomized. People work on GUIs, and don't care about drawing/painting routines. Those who care, are often far away from the numerical world. The numerically-oriented folk often disregard with a lot of desinvolture the attempts to put the Haskell numerical classes in an abstract algebraic framework (really useful from the point of view of code reusing), etc. I have the impression that this is changing, but slowly, while the scientific computation/visualization world is marching very fast, not only in the direction of very-fast-even-more-dirty routines, but also in the direction of new conceptualization/representation models (like, e.g., "actors" in VTK). Jerzy Karczmarczuk Caen, France _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
