Re: [boost] [multi_array] Negative strides

Subject: Re: [boost] [multi_array] Negative strides
From: John Reid (j.reid_at_[hidden])
Date: 2009-06-08 09:29:06

Chard wrote:
> "John Reid" <j.reid_at_[hidden]> wrote in message 
> news:h0ispf$e40$1_at_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.