Re: [eigen] Multi Dimensional Arrays

[Rhys Ulerich <rhys.ulerich@xxxxxxxxx>]

> I feel your pain, and I've been working on a multidimensional array library
> that's designed to let Eigen do all the matrix math:
>
> http://code.google.com/p/ndarray/

Jim, you're my hero for the following reasons:

1) Indexes and shape information have the same sign-edness.  It drives
me crazy that MultiArray requires
    for (index i = 0; i < (index) bar.shape()[0]; ++i) {}
    to avoid hitting compiler warnings.  And that doing The Right
Thing (TM) for generic MultiArray routines where non-zero-indexed
directions are a possibility gets seriously ugly seriously fast.

2) You maintain some storage ordering information in the type.  I've
rolled this (badly) atop MultiArray using MPL and absolutely hate my
approach.  Any chance you could extend Array<T,N,C>'s C semantics so
that C < 0 implies a column-major contiguous ordering?  With some
clever use of transpose() you could probably pick up a lot of things
for free.

3) You make it easy to create data which is non-contiguous in some
directions.  This is hackable atop MultiArray but requires using some
protected functionality from multi_array_ref.  I've been forced to go
this way to pad multidimensional arrays where I'm performing
real-to-complex FFTs on the final dimension.

I'm sure I'll find more reasons in the near future.  Ronald Garcia's
mentioned once or twice that he's interested in rolling a rewrite of
MultiArray that handles deep vs shallow semantics better.  You might
try interesting him in hacking on what you've got.

- Rhys