On Fri, 16 Oct 1998, Simon Peyton-Jones wrote:
> 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.
I guess that this is one of those points where Jan mentioned there's a
line between scientific & engineering computing. From (my admittedly very
limited) experience, there's a lot of scientific computing which boils
down to the variations on the same basic problem formulation, e.g., some
species of system of differential equations, finding eigenvalues, etc.
This area would be well served by being able to link to Mathlab, LINPACK,
etc, but the amount & complexity of the gluing to be done would be
relatively small so that working with C or Fortran wouldn't really bite
you. So I suspect that, if you're talking about `max gain for least pain'
in Real World applications, it's low pain but also low gain.
But there's a lot of problems, probably more in the hazy region between
science & engineering, where `numerically intensive' algorithms are
developed which don't look anything like existing classical techniques.
Here the issue is to generate CORRECT results REASONABLY QUICKLY, ie, the
time has to be within a factor of 3-4 times of a C implementation but this
slowdown is acceptable if you are more confident your infant algorithm is
correctly implemented in your infant code. As an example, I've got several
variations on the standard idea of a Markov Random Field being used in my
current work which require heavy modifications within the various solution
schemes for MRF problems so that I can't interface to an existing MRF
solver (although I can use ideas from looking at their source code). I've
spent many hours searching for errors occasioned by the low-level nature
of C; I'd have loved it if I could have saved myself time OVERALL by
using a functional language.
So in my opinion, although it's much more work, you'd get much more `Real
World' usage by concentrating on rapid development scientific/engineering
computing.
___cheers,_dave__________________________________________________________
email: [EMAIL PROTECTED] I _never_ buy items advertised by those
www.cs.bris.ac.uk/~tweed/pi.htm annoying cards that drop from magazines
work tel: (0117) 954-5253 or by bulk e-mail on principle.
