Re: [eigen] Multi Dimensional Arrays

[ Thread Index | Date Index | More Archives ]

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:

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.


Mail converted by MHonArc 2.6.19+