Designing a matrix library for D

[Mason McGill via Digitalmars-d]

On Monday, 23 June 2014 at 16:45:28 UTC, bearophile wrote:
I'm glad to hear there's interest in this! I've actually been 
working on a generic multidimensional array library myself (on 
and off) for the past few months (I'm hoping to have a 
well-documented dub package by the end of the summer). It's a bit 
of a hybrid between Julia's `AbstractArray`, NumPy's `ndarray`, 
Numba, and std.range, and I think it has a very "D" feel.

It is, however, designed for processing sampled signals (rather 
than matrix algebra), which may be more or less in line with 
different people's interests.

Concepts:
   InputGrid: anything with a size (size_t[n]) and n-dimensional 
opIndex.
   OutputGrid: anything with a size (size_t[n]) and n-dimensional 
opIndexAssign.

Functionality:
   - Lazy `map` and `reduce`.
   - Lazy `zip` with built-in broadcasting.
   - Lazy n-dimensional convolution and cross-correlation.
   - Lazy sampling and interpolation.
   - `collect` to force evaluation.
   - Element-wise operators and and fancy indexing via mixins*.
   - Everyone's favorite MATLAB-style constructors
     (`zeros`, `identity`, `meshGrid`, etc.)
   - Audio/Video and JSON I/O, via GStreamer (though this
     probably ought to be a separate package).

*Because D doesn't allow UFCS for operators, which is silly, but 
that's the way it is.

Other features:
   - Compatibility with an automatic binding
     generator I've been working on.
   - Testing, because I've been using this at work :)

If people want to use this, it might make sense to add linear 
algebra to this package rather than building a separate, 
incompatible algebra library (see this thread: 
http://comments.gmane.org/gmane.comp.lang.julia.devel/14533).

I did a lot of thinking about the level of abstraction that would 
be the most useful, and I settled on something like Julia's 
`AbstractArray` because it fits into D nicely ("like ranges, but 
different!") and easily maps onto something that can be passed to 
other languages (a block of memory with size/strides metadata). 
As in Julia, I decided to make rank (`nDim!grid`) a compile-time 
entity since

1) Writing rank-branching code for NumPy is cumbersome and error 
prone; rank should be part of overload resolution.
2) It speeds up component-programming-style operations without 
requiring leaky abstractions (having to specialize on concrete 
grid types).

It's a busy week so I probably won't be able to follow this 
thread, but I wanted to let you know I was working on this to 
avoid duplicated efforts, etc.

Cheers,
Mason