Re: [boost] Try out a multi-dimensional adapter class template?

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:
>
> [SNIP]
>
>>> My version indexes only elements; sub-arrays are not supported. It
>>> wouldn't be efficient, since elements would not be contiguous in
>>> general.
>>
>> 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
> row-major
> 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
> argument.

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

>
> [SNIP]
>> 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
> stand-alone.

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.

Robert Ramey

> Daryle W.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost