A few comments:
>> Could Haskell ever be used for serious scientific computing?
>> What would have to be done to promote it from a modelling
>> tool to a more serious number crunching engine? Maybe not
>> necessarily competing with Cray, but not terribly lagging
>> far behind the other languages?
>
>Short answer: I think so, but it's a lot of work.
>
>Going head to head with FORTRAN is very challenging. FORTRAN
>compilers deal with a first-order, strict, language with explicit
>storage management -- and they have two decades lead.
>
>First, you absolutely have to store arrays of unboxed values;
>having arrays of pointers to thunks is a real killer. The Clean
>people have done a lot of good work on this, and with a bit of
>multi-paramter type class magic I think one can use unboxed arrays
>without it polluting your program too much.
For the programmer unboxed arrays in Clean 1.3 appear just as an attribute
to the type name.
Example: a vector is an unboxed array of reals:
:: Vector :== {# Real}
and that works the same way for matrices
:: Matrix :== {# Vector}
where the '#' indicates unboxing.
Then you can start defining your operations with these types. Let's add two
vectors:
add :: Vector Vector -> Vector
add x y = { xx + yy \\ xx <-: x, yy <-: y}
This is called array comprehension. The '<-:' extract elements from an
array, like the '<-' extracts elements fomr lists in Clean.
To work with infix operators you can instantiate (+) for vectors, matrices,
tensors just by writing this recursive instantiation:
instance + {# a} | + , ArrayElem a
where
(+) a b = { aa + bb \\ aa <-: a & bb <-: b}
>I just do not know how important update in place is. With programs
>that manipulate a few very large arrays the detailed storage management
>of those arrays becomes rather important. Sisal did an incredibly
>good job of this. Laziness makes that harder. Clean allows the
>programmer to get update inplace via uniqueness types.
Concerning the importance of updates, I would distinguish between two large
groups of algorithms. They are - with their favourable storage scheme and
the most important operation:
full, small systems -> direct methods -> updates
sparse, large systems -> iterative methods -> matrix vector
multiplication,
dot products
Two examples: You don't want to use a direct method for a matrix in a
sparse storage scheme, because random access in such matrices is slow and
typically the matrix fills in (and isn't sparse anymore). You don't want to
run an iterative method with a full matrix either, as the matrix vector
product (in each iteration step) becomes really expensive.
Another rule of thumb: In direct methods the main 'information' is located
in the matrix elements, which are accessed and updated. In iterative
methods the information is contained in vectors, which are added,
multiplied with a scalar or a matrix - the result being another vector.
There is often only one matrix involved in iterative methods, being
multiplied with in each step.
>[...]
>Another approach is to compete not head-to-head on speed, but on
>cunning. Get a good library of numeric procedures (e.g. Mathlab),
>interface them to Haskell, and use Haskell as the glue code to make
>it really fast to write complex numerical algorithms. 99% of the
>time will still be spent in the library, so the speed of the Haskell
>implementation is not very important. This looks like a jolly productive
>line to me.
Most parts of Matlab (which stands for Matrix Laboratory and really is
good) are direct calls to LAPACK, a huge library of basic numerical tasks,
written in FORTRAN and C (and maybe more) and specialized for many
platforms.
So using Matlab routines is somehow an indirect step. You don't have the
nice graphic features of Matlab in LAPACK of course.
Cheers, thorsten.
o-------------------------------------------------------------------o
T h o r s t e n Z o e r n e r
Computing Science Institute Catholic University of Nijmegen
snail : Postbus 9010 6500 GL Nijmegen, The Netherlands
office: +31 (24) 36-52069 fax: +31 (24) 36-52525
email : [EMAIL PROTECTED] visit: Toernooiveld 1, room A-6032
url : http://www.cs.kun.nl/~zoerner/
o-------------------------------------------------------------------o
