Subject: Re: [boost] Try out a multi-dimensional adapter class template?
From: Robert Ramey (ramey_at_[hidden])
Date: 2013-10-09 12:41:12
Daryle Walker wrote:
>> From: ramey_at_[hidden]
>> Date: Tue, 8 Oct 2013 21:25:44 -0800
>> Daryle Walker wrote:
>>>> From: ramey_at_[hidden]
>>>> Date: Tue, 8 Oct 2013 08:50:54 -0800
>>>> Daryle Walker wrote:
>>> My version indexes only elements; sub-arrays are not supported. It
>>> wouldn't be efficient, since elements would not be contiguous in
>> To me this is an absolutly essential feature and one reason I
>> love this library.
> C spoiled us with their multidimensional arrays actually being nested
> linear arrays. So subsets was really easy (as long as you followed
> order). I think it's more of a secondary action of the Multi-Array
> concept, rather than primary (like element indexing).
>>> Create a new array object of the smaller size and use
>>> (c)apply to copy over what you want.
> Which is probably what Boost.Multiarray does in the background of its
> slicing methods (that return a copy).
I don't think so. I think it just re-maps the indices on the fly. This
is more or less what I would have to do by hand if I want to
copy out a slice for subsequent faster access. It will be very,
very, hard to convince me that this is not an essential feature.
>> You have to walk all the elements to create the new
>> contiguous array. It's not clear how you would do this
>> in your library. The current one does it all automatically
>> taking care of strides and all that. Your scheme just
>> ignores the utility of this feature.
> The automatically-defined copy constructor and assignment work if all
> the template parameters are the same. But for other combinations, do
> you want to follow in-memory order, or match index-tuple to (mapped)
> index-tuple? That's why I didn't pick a default.
Basically, the memory order may be configurable, but it should
(mostly) be irrelevant to the usage of the library. This would
affect timings of creating mapped slices - but wouldn't really
affect the usage of an array.
> If you're doing copying, you should call (c)apply for the smaller
> container. Make sure to pass the non-applying container as a lambda
well, I'd have to think about what this means. It is not necessary
to do anything special with the multi-array library. Just create
a subview and walk the elements of the subview in the desired
order. Or use a standard copy using the interator interface. This
is going to be very hard to beat as a transparent, efficient
>> It seemst to me that the mult-array has everything we need
>> and that very little is to be gained by trying to replace it.
> array_md is designed to be an upgrade of boost::array, not compete
> with Boost.MultiArray. My multiarray adapter is a first draft at
> something new for me. They're both made to be possible additions to the
> Standard, which wouldn't have Boost.Multiarray, i.e. they have to be
well maybe I'm just confused by the calling it "Multiarray". Since
it's an enhance to array which is a facade on plain old c arrays,
and plane old c arrays can have more than one dimension, maybe
it should be just considered an ehance ment to std::array.
if one is thinking about adding to the standard (waaaaaay premature in my
opinion), then maybe it's boost.multi-array which should be added
to the standard.
I'm still thinking that boost multi-array is not appreciated to the extent
that it should be. I would like to see it enhanced to accomodate
compile time extents. Of course even that would have a ripple effect
into the multi-array concepts so maybe it's too hard to do.
> Daryle W.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk