Boost logo

Boost Users :

Subject: Re: [Boost-users] [multi_array]bug in strides calculation with some storage orderings
From: Larry Evans (cppljevans_at_[hidden])
Date: 2012-01-01 20:40:22


On 12/30/11 11:02, Larry Evans wrote:
> If I understand correctly, the multi_array storage order determines
> which strides are larger than others. In short:
>
> if( order[I]>order[I+1])
> then stride[I]>stride[I+1]
>
> However, the output from the attached code shows that this is not
> always true.
[snip]
Sorry, I should have read the example on:

http://www.boost.org/doc/libs/1_48_0/libs/multi_array/doc/user.html#sec_storage

which contains:

  // Store last dimension, then first, then middle
  array_type::size_type ordering[] = {2,0,1};

which I think implies the calculate order for the strides is
  the last dimension 1st(2 is last dimension),
  then the first dimension 2nd(0 is the middle dimension),
  then the middle dimension 3ird(1 is the middle dimension).

which is the inverse permutation of what I was thinking
the storage ordering meant. IOW, I thought storage order:

  {2,0,1}

meant the middle dimension had the smallest stride(value 0 in above),
the last dimension had the next smallest stride(value 1 in above),
and the first dimension had the largest stride(value 2 in above).
That interpretation would mean that the calculation order for the
strides would be:

  the middle dimension stride would be calculated 1st,
  then last dimension would be calculated 2nd,
  then the first dimension would be calculated 3ird.

However, I now realize that assumption was wrong.

Sorry for noise.

-regards,
Larry


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net