Re: [boost] [multi_array] Negative strides

Subject: Re: [boost] [multi_array] Negative strides
From: Ronald Garcia (garcia_at_[hidden])
Date: 2009-06-10 14:33:30

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_at_[hidden]> wrote in message news:h0ispf$e40$1_at_[hidden] 
>> ...
>>> 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?