Chard wrote:

"John Reid" <j.reid@mail.cryst.bbk.ac.uk> wrote in message news:h0ispf$e40$1@ger.gmane.org...

...

I could not find any support in boost::multi_array for negative strides. Does anyone know what the rationale was for not implementing them?

I'm sure I recall using them in the past; had to ensure the end index was lower than the start, i.e. its counting down, and [start,end) still applies.

They do seem to work for me as long as I don't want to access the first element of the original array. See the following code: #include <boost/multi_array.hpp> #include <iostream> int main( int argc, char * argv[] ) { using namespace boost; const size_t size = 4; typedef multi_array< double, 1 > array_type; array_type my_array( extents[ size ] ); my_array[0] = 1.; my_array[1] = 2.; my_array[2] = 3.; my_array[3] = 4.; typedef multi_array_types::index_range range; array_type::array_view< 1 >::type my_view = my_array[ indices[ range( 3, -1, -1 ) ] ]; //array_type::array_view< 1 >::type my_view = my_array[ indices[ range().start( 3 ).finish( -1 ).stride( -1 ) ] ]; for( size_t i = 0; my_view.size() != i; ++i ) { std::cout << i << " : " << my_view[ i ] << "\n"; } return 0; } If I change the range( 3, -1, -1 ) to range( 3, 0, -1 ) the code runs smoothly and I get exactly what I expect. Trying to access the first element of the original array using finish=-1 in the range constructor causes an assertion at array_view construction time. Everything works as expected if I #define BOOST_DISABLE_ASSERTS but this isn't something I want to do in general. Either the library was designed with negative strides in mind and it is just the assertions that are stopping me using them or they were never part of the original spec and are not safe to use. In either case I can't find them mentioned in the documentation. Could the owner of the library clear this up? John.

Hi John, multi_array was designed to support negative strides. This notion probably only appears in the discussion of storage order, where some dimensions of a multi_array can be stored backwards rather than forwards. It looks like there's a bug in the asserts for start and finish. The assert for start should be BOOST_ASSERT(index_bases[n] <= start && start < index_bases[n]+index(extents[n])); // changed <= to < The most precise assert for finish must be more nuanced. finish represents "one past the end" of a range, which as you assumed means one less than the desired final value in the case of negative strides. Best, Ron On Jun 8, 2009, at 8:29 AM, John Reid wrote:

Chard wrote:

...

"John Reid" <j.reid@mail.cryst.bbk.ac.uk> wrote in message news:h0ispf$e40$1@ger.gmane.org ...

...

I could not find any support in boost::multi_array for negative strides. Does anyone know what the rationale was for not implementing them? I'm sure I recall using them in the past; had to ensure the end index was lower than the start, i.e. its counting down, and [start,end) still applies.

They do seem to work for me as long as I don't want to access the first element of the original array. See the following code:

...

If I change the range( 3, -1, -1 ) to range( 3, 0, -1 ) the code runs smoothly and I get exactly what I expect. Trying to access the first element of the original array using finish=-1 in the range constructor causes an assertion at array_view construction time. Everything works as expected if I

#define BOOST_DISABLE_ASSERTS

but this isn't something I want to do in general.

Either the library was designed with negative strides in mind and it is just the assertions that are stopping me using them or they were never part of the original spec and are not safe to use. In either case I can't find them mentioned in the documentation. Could the owner of the library clear this up?

Ronald Garcia wrote:

...

multi_array was designed to support negative strides. This notion probably only appears in the discussion of storage order, where some dimensions of a multi_array can be stored backwards rather than forwards.

I've checked a bug-fix into the boost trunk, and made John's example program a regression test.

Great, thanks!