Scientific computing with D

[Bill Baxter]

On Fri, Jan 30, 2009 at 10:23 PM, Lars Kyllingstad
<public at kyllingen.nospamnet> wrote:
> I think D is, or at least could be, the scientific programming language of
> the future.

Agreed!  Numerics is one place where D fits nicely.

> [...]
> 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.

> 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.

...and not GPL, preferably.  :-)

The goal sounds great.  I'm certainly willing to help out.

To me it seems one of the first things you need to get nailed down is
how to represent multidimensional data.  Both dense, strided, and --
for 2D -- common sparse and BLAS formats.   Probably this can be done
at the concept (compile-time interface) level without having to go
into implementation details.  But it might also be nice to have some
concrete implementation nailed down too, so not everything is built as
a giant house of template cards.  Once you have that, then any package
that can work with that concept or array format will be able to share
data pretty easily.

But it's not so easy.  Even now I use 3 different libraries at
different times for different things.
* I have MatrixT/VectorT,  fixed-size dense matrix and vector, whose
2D and 3D versions have some special operations like "cross product"
* I have Dflat, which provides dynamically-sized Matrix types that
match what BLAS accepts.  And also a few dynamically-sized sparse
formats that work with various sparse libs.
* I have MultiArray which is a generic container for N-dimensional
strided data, with dynamic number of dimensions and size.

On the last one ... I consider that one a bit of a failed experiment.
Dynamic number of dimensions causes too many headaches and is not
really useful very often.  I think Fawzi is brewing a fix-dim N-d
array of his own, or was at one point.

But anyway uniting all these things under a single library or even a
single concept would be significant work.

--bb