Scientific computing with D

[Lars Kyllingstad]

I think D is, or at least could be, the scientific programming language 
of the future. Here's why -- and possibly how:

A couple of years ago, I took a university class called Numerical 
Physics. After finishing the course, I was left with the impression that 
numerical computing was all about squeezing every last bit of 
performance out of the computer -- that unnecessary operations and 
function calls should be avoided at any cost, even if the resulting code 
is full of nasty hacks and tricks, making it completely illegible and 
utterly unmaintainable. And of course, in many cases this is true.

Now, however, I have a bit more experience in the field and I know that 
it is not always so. In numerics, as in other areas of programming, it 
is a trade-off between development time and execution time. 
Traditionally, if one has a desperate need for speed (sorry), one uses 
FORTRAN, C or C++. The programs run very fast, but can be hard to 
develop, debug and maintain. For less processor-intensive tasks one uses 
Matlab, Mathematica, etc. which have a lot of built-in functionality and 
make for rapid development, but programs run at a snail's pace.

With D one has the best of both worlds. I've used both C++ and 
Mathematica for numerics in the past, but now I use D almost 
exclusively. I find it a lot easier (and more fun) to code in than C++, 
and I spend a LOT less time debugging my programs. On the other hand, 
calculations that would take an entire day in Mathematica are finished 
in a matter of minutes using D.

It's a fact that D programs don't have the performance of C(++) ones, 
but that, I think, is just a matter of time (pun not intended). It's a 
relatively new language, and the compilers are still somewhat immature.

The one thing I miss the most, however, and which I think is necessary 
for D to "take off" as a scientific language, is a native D scientific 
library.

Searching dsource, I find that many nice modules and libraries have been 
made already:
  - MultiArray (Bill, Fawzi)
  - dstat (dsimcha)
  - blip (Fawzi)
  - MathExtra, BLADE (Don)
  - Scrapple/backmath (BCS)
  - Scrapple/units (BCS)
  - bindings to GSL, BLAS, etc.
  - ...and probably more

Myself, I've written/ported some routines for numerical differentiation 
and integration, one- and multi-dimensional root-finding and some very 
basic linear algebra, but so far only for personal use. Currently, I'm 
thinking of porting QUADPACK to D.

I think it would be really nice if many or all of the above mentioned 
things could be collected in a single library, together with all kinds 
of other stuff. Something like the GSL, only written in D. (In my head 
it's called SciD. At first I thought of DSL - D Scientific Library - but 
that acronym is used all over the place.) I haven't the time, nor the 
skills, to write an entire such library myself, but I'd be happy to 
contribute where I can.

Here are some design goals I find important:
  - sensible, logical and tidy package hierarchy
  - access to high-level functionality for rapid development
  - access to low-level functionality for performance
  - make use of D's awesome compile-time functionality
  - reusability, pluggability and extensibility

(By the last point I mean that if one method doesn't work it should be 
quickly and easily replaceable in code with something else. This is 
achievable through the use of templates and interfaces, and ties in with 
the second point.)

So, what do you think? Am I making any sense? Am I the only one 
interested in these things?

All of the above are, of course, my personal opinions. What are yours?


-Lars