$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] RFC: runtime-flexible arrays
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-02-16 02:17:32
On 02/16/2012 02:42 AM, Bjoern Andres wrote:
> Hi everyone,
>
> I have written a header for runtime-flexible multi-dimensional views and
> arrays and would love to get comments and feedback from the boost
> community:
>
> tutorial code : http://tinyurl.com/7hdldc9
> main website : http://www.andres.sc/marray.html
> doxygen reference doc: http://www.andres.sc/marray/doc/index.html
> git repository : https://github.com/bjoern-andres/marray
> tech report : http://arxiv.org/pdf/1008.2909v1
>
> Unlike in Boost.MultiArray, the dimension of arrays is not a template
> parameter in Marray.
In Boost.MultiArray, the dimension is not a template parameter; the
number of dimensions is.
I assume you always use the maximum number of dimensions, and treat
arrays of size N*M the same as arrays or size N*M*1*1*1*1
> Other features include
>
> - runtime-flexible dimension, shape, size and indexing order (first or
> last coordinate major order)
> - arithmetic operators with automatic type promotion and expression
> templates.
This should be decoupled from the container itself.
Algorithms and containers are different things.
If you're doing expression templates, you should re-use Boost.Proto to
have a proper framework to deal with expression trees.
And if you're supporting arithmetic operators, it will be expected that
you generate high-performance parallel code (like Blitz++, Eigen, or NT2
-- I am the author of the latter).
I'm not sure type promotion is such a good idea.
> - access to entries via coordinates, scalar indices and STL-compliant
> random access iterators.
I find it confusing that iterators flatten the data. I'd rather they
iterate on the external dimension.
If you want to iterate over flattened data just make a view with a
flattened shape and iterate that.
Also if you support 1D and nD access, why not also support 2D or 3D
access within a 4D array?
Something else, what we do in NT2 is that we use an iliffe index as
described in the NRC (Numerical Recipes for C) book. This allows us to
make a view that extracts an arbitrary rectangle or hypercube and to add
padding between lines without extra modulo operations.
Do you use something like that as well?