Re: [boost] [multi_array] Is there interest for an [index_list] library?

Subject: Re: [boost] [multi_array] Is there interest for an [index_list] library?
From: Rhys Ulerich (rhys.ulerich_at_[hidden])
Date: 2011-04-10 16:16:10

> I would like to gauge the interest of the community in a library that can
> serve 1) as a complement to Boost.MultiArray and 2) as an alternative to
> Boost.MultiArray.

Caveat, I've taken only the briefest of glances at what's in the sandbox...

> For the first type of use, an example of the candidate library's
> capabilities is that it makes available a special iterator "it" that allows
> to browse all the elements of a MultiArray "m". This special iterator has an
> it.indices() members that returns a "list" Collection of indices (i.e. an
> IndexList) such that "m(list)" and "*it" are the same elements. This can be
> useful for functions whose effect on an element of "m" depends on where this
> element is situated in "m".

Does the functionality work atop the MultiArray concept or atop
boost::multi_array and boost::multi_array_ref?  One can linearly walk
the contents of the latter using iterators foo.data() and foo.data() +
foo.dimensionality.  I think only the MultiArray concept would need
further capabilities for a linear walk independent of the
dimensionality (as .data() isn't part of the concept).

A "position-dependent" behavior can be achieved (atop multi_array and
multi_array_ref) by taking the distance between foo.data() and the
current iterator and then playing some games with foo.strides() or
std::distance().  I believe the same can be achieved atop the pure
MultiArray concept using foo.origin().  No need to extend the concept
(though the required couple of lines would be frustratingly lengthy).

Personally, I've found that writing three overrides of most methods is
sufficient to take advantage of the contiguous storage guaranteed by
boost::multi_array and boost::multi_array_ref while allowing the
general MultiArray cases to work.  Aside from runtime dimension
selection, what does 'box' add beyond the current extent_gen-based
capabilities.  (Compile-time) dimension-independent code can be
written by templating on the MultiArray NumDims parameter
(http://agentzlerich.blogspot.com/2010/01/providing-fill-and-foreach-algorithms.html
is an example).  Runtime-decisions about the dimensionality of a
MultiArray definitely are interesting but I'm unimaginative and can't
think of the use case...

> The second way to use the candidate library is as an alternative to
> Boost.MultiArray of dynamically chosen (execution time) dimensionality.
> Moreover, the elements do not necessarily need to be arranged in a
> multi-dimensional "box", as is the case in a MultiArray. For example, a
> "simplex" organization of the elements is already implemented.

I'm afraid I can't begin to speak intelligently about the simplex
organization...

I don't think I'm your target audience so take all of this with a
grain of salt.  I very much appreciate your attempts to further
improve the MultiArray concept as I use it heavily in my own work.
Also, just cause I find it interesting, ndarray is a fairly cool
alternative (https://code.google.com/p/ndarray/).

- Rhys