Daryle Walker wrote:
From: ramey@rrsd.com Date: Tue, 8 Oct 2013 08:50:54 -0800
Daryle Walker wrote:
I added a new class template for my library at https://github.com/CTMacUser/ArrayMD. It's called "multiarray," and it's an adapter class like stack and queue. But the new interface is only for accessing elements. Besides the element and container types, the template header for the class takes the number of dimensions. The class uses at, operator [] and operator () to access an element. It has methods to read/write the shape of the array and the priority of each index. There are no methods to change the number of elements stored; you have to either use a fixed-size container or sub-class the multi-array to add methods to change the size. (The container sub-object is protected, like the Standard adapters.) I split the main code into two base class templates, because the code for computing the offset from an index tuple and the code for referencing an element were nearly distinct. This really screws up my attempt at Doxygen comments. Any ideas? Or is my case too complex for what Doxygen's author thought could be handled.
I've looked at the document above. It would seem to me that this is similar or equivalent to boost.multi-array with extents set at compile time rather than at runtime. Is my understanding of this correct? If not how is it wrong.
Both templates get the number of dimensions as a compile-time parameter and the actual extent values at run-time. The Boost version can take the extents and priorities in the constructor, while my version has to change those attributes in separate call(s). But it seems that construction time is the only opportunity for the Boost version to use a different index priority; it can't be changed later, unlike mine.
Hmm- I'm not sure what "index priority" refers to.
The Boost version is a full container, including allocator support. There are also mutable and immutable view classes. My version is an adapter, and punts storage considerations into what container type is used. Since my version holds the container as a protected member, view classes are nonsensical.
views are an essential feature of multi-array to me.
The Boost version was designed during a time of broken C++98 support, while mine was designed for compliant C++11 support. The new version can take advantage of newer features. My version uses Standard classes to take indices and to get & set extents and priorities. The Boost version uses a lot of auxiliary classes. The Boost design is spread over many headers; my version is compact enough to be a done-in-one header (but it does less, too).
I'm sure that many libraries could be more easily writen with more up-to-date tools. But I'm not convinced that that is a reason for doing so. Personally I'm not really concerned about the implementation as long as it's efficient.
Neither version provides methods to directly change the number of elements. The Boost version can change its element count through its resize method.
Hmm - These statements seem to conflict - It seems to me that multi-array can have all the extents adjusted at run time. I can see that this facility could imply extra coding and loss of runtime efficiency. That was the motivation for my original question - it seemed to me there might be a motivation to have the same thing with more stuff fixed at compile time to make it faster at the cost of runtime configurability.
My version can't at all, except through derived classes. But my version decouples the elements stored and what's needed. You only crash when referencing an element beyond the container's bounds. It was designed with std::array as a base container. It should be efficient when the desired size stays close to the array's fixed size.
Hmm - doesn't one fix the array size to the "desired size" at compile time? Aren't they equal. I'm not getting this.
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.
Create a new array object of the smaller size and use (c)apply to copy over what you want.
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.
Fancy indexing, outside of priorities, is not supported either. (Since there's no sub-arrays nor views, the chain-of-operator[] syntax is not supported.)
Another very, very useful feature of the current multi-array.
I've used multi-array on various occasions and have been struck> by how well it's done. (and better than average documented). Have you considered just augmentting multi-array with some constructors or "re-sizer" which use extents defined as template parameters? It seem that if you could do this, one would be able to leverage all that is done already. Even if this is not possible, it would be nice to have an interface as close as possible to mult-array to leverage on one's understanding of both libraries.
They have different interfaces. Neither of them can define the extent values at compile-time.
That is the feature that I had thought your library might be adding.
Another class in that GitHub repository, array_md, does do that. However, it's a variadic extension of std::array, and so does not have any of the storage or indexing options that Boost.Multi-Array has. My multiarray adapter was started from so many complaints that array_md doesn't support anything besides row-major order, making it less desirable for all the math & science junkies that wanted column-major (or scrambled-priority) storage.
All this is supported by the current multi-array. Why not just focus your efforts in enhancing multi-array to include compile time setting of array extents. Note that the multi-array library includes multi_array_ref which is designed to provide the multi-array interface to an array which has already been allocated. Natually in this case it doesn't do any allocation on it's own. 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. Robert Ramey Daryle W.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost