Subject: Re: [boost] [multi_array] Negative strides
From: Ronald Garcia (garcia_at_[hidden])
Date: 2009-06-10 14:33:30
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
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.
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk