"S.D.Mechveliani" wrote:
[snip]
> And why the dense matrix representation is better for Haskell?
> Rather i would expect it is the sparse one.
I really don't think this kind of comparison is going to be very meaningful.
I've written some sparse matrix code in C myself. Since memory is often
as important as CPU-time (it was in that case) you work tremendously hard
getting the most efficient storage representation. For example, you
use elements of an array at one time as pointers in a circular list, at
another time as column indices. You store rows if possible as consecutive
elements in an array, rather than as linked lists. (This is of course
also a big CPU time saver.) And so on. Of course
this kind of implementation is going to completely assassinate any
Haskell sparse-matrix routines that just maintain rows as lists, but that
proves nothing.
Suppose I were writing a new sparse matrix package. (I certainly won't;
Netlib, which I highly recommend if you want well-written numerical code,
almost certainly has anything I want, written better than I could write it.)
I doubt if I would use Glasgow Haskell, because it takes geological ages
to compile compared with gcc, and the small gain from GHC's sophisticated
type system would be outweighed by irritation at the syntax required to
access unboxed arrays fast and unsafely. But so what? Only about 0.01%
of programmers can write numerical code well anyway. (I'm not one of them.)
To them the difficulties Haskell is designed to cure are as nothing compared
with the difficulties of devising exactly the right algorithm to
do something fast and accurately. The rest of us
would be better advised to stick to the sort of things Haskell is good at.
And if I wanted to do linear algebra or compute a log-gamma function
in Haskell I would get the relevant code from Netlib or some similar
source and link it in.
