[Boost-users] Slicing multi_array

[James Amundson]

Hi,

I want to write a function that operates on one-dimensional
multi_array's and use it to modify the columns of a two-dimensional
multi_array. I thought that this would be a straightforward application
of slicing, i.e., views with dimensional reduction. However, my first
attempt to do so does not compile. (Please see the attached source
code.) When I try to pass a view to my function, I get:

error: invalid initialization of non-const reference of type
boost::multi_array_ref<double, 1ul>& from a temporary of type
boost::detail::multi_array::multi_array_view<double, 1ul>

I have now read the section on views and subarrays in the multi_array
reference documentation several times, but I do not see how I can do
what I want.

Any suggestions?

Thanks,
Jim Amundson

[Rhys Ulerich]

I want to write a function that operates on one-dimensional multi_array's and use it to modify the columns of a two-dimensional multi_array. I thought that this would be a straightforward application of slicing, i.e., views with dimensional reduction.

Any suggestions?

Attached version of it working, I think.   Not quite what you had in mind since my attachment includes saves the view as a temporary and then passes the view by reference to the function fill_array.

- Rhys

[James Amundson]

Thanks. That works, but it's really ugly.

 I don't understand why a slice of a multi_array(_ref) isn't simply a multi_array_ref. The current implementation seems to make dealing with slices unnecessarily complicated. The documentation on views is also very thin. Can anyone explain the rationale behind the design?

Thanks again,
Jim

[Rhys Ulerich]

Thanks. That works, but it's really ugly.

Agreed.
 

 I don't understand why a slice of a multi_array(_ref) isn't simply a multi_array_ref. The current implementation seems to make dealing with slices unnecessarily complicated. The documentation on views is also very thin. Can anyone explain the rationale behind the design?

All I'm aware of is in this article:
 
@article{garcia2006multiarray,
    title = {{MultiArray: a C++ library for generic programming with arrays}},
    author = {Garcia, R. and Lumsdaine, A.},
    journal = {Software: Practice and Experience},
    year = {2005}
    volume = {35},
    number = {2},
    publisher = {John Wiley \& Sons, Ltd.},
}

which shows some inheritance diagrams that may explain what you're after, but I'm unsure if it will answer your question directly.

- Rhys

[James Amundson]

Thanks. The article was very helpful. The section "Simulating reference types with classes" explains why it isn't possible to pass a temporary in my original example. I still don't see why an array view is not simply an array ref. I am willing to believe that there might be a good reason, albeit not described in the paper or reference documentation. However, I really think the slicing portion of multi_array is broken.

For the record, I now have a version of my test program that seems to be optimal for my application. The templated solution suggested by Rhys causes problems in my application because the actual function I want to implement is virtual member function. I've worked around the problem by having a separate wrapper function.

Here are my general observations:

1) The multi_array_view type is "hidden" to the extent that it only appears in the "detail" namespace and is largely undocumented.

2) All view/slicing operations return a multi_array_view type.

3) It is easy to get a multi_array_view from a multi_array_ref (et al).

4) It is difficult (impossible?) to get a multi_array_ref from a multi_array_view.

5) Because of (2), (3) and (4), it makes the most sense to write one's interfaces in terms of views if one ever expects to do slicing.

6) Because of (1) and (5), I find the interface to be broken.

7) Minor point: I can avoid the problem of not being able to pass a temporary by accepting the overhead of passing a copy instead of a reference. For my application, that's a win.

I have attached my final working version of the example I originally gave.

--Jim Amundson