Re: [eigen] Multi Dimensional Arrays

[Jim Bosch <talljimbo@xxxxxxxxx>]

On 02/09/2011 08:36 AM, Rhys Ulerich wrote:
> > 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.

I'd thought about it, but I didn't see a lot of value in it originally, 
because I was mostly concerned with speeding up nested iterators, and 
those don't benefit at all from column-major contiguousness.  But 
transpose certainly would benefit (currently, two transposes destroy all 
the compile-time contiguousness information), and I could see how 
mappings to Eigen or other matrix libraries would benefit as well.  I'll 
look into it.

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

This was exactly why I gave up on using MultiArray.  I didn't want to be 
forced to start with all my data strictly owned by some container.

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

Interesting.  I hadn't followed MultiArray much once I decided to go my 
own way, but I'd certainly be interested in seeing what some experienced 
boost reviewers think of some of my design decisions in ndarray.  Is 
there a concrete redesign project I should look into somewhere, or is 
this something I should just ping the boost developer list about?

Anyhow, I'm glad you like ndarray!  My own group has been using it 
extensively for a little while, but the user base is still pretty small 
and it will only get better if other people with other needs try it out.

Jim