Daryle Walker wrote:
From: ramey@rrsd.com Date: Tue, 8 Oct 2013 21:25:44 -0800
Daryle Walker wrote:
From: ramey@rrsd.com 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