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
