Re: [eigen] issue 77: map with stride

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Mon, Jan 18, 2010 at 11:33 AM, Hauke Heibel
<hauke.heibel@xxxxxxxxxxxxxx> wrote:
> On Mon, Jan 18, 2010 at 11:15 AM, Gael Guennebaud
> <gael.guennebaud@xxxxxxxxx> wrote:
>> On Mon, Jan 18, 2010 at 9:48 AM, Hauke Heibel
>> <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>>> Personally, I don't like the notion of inner and outer stride. For 2D
>>> objects, there should only be one stride function. Conversely, the
>>> stride for 1D objects should either not be called at all or it should
>>> be one. But as I said, maybe I am not yet understanding the problem
>>> this causes within Eigen.
>>
>> As Benoit explain in his example, taking a row from a column major
>> matrix yields a vector object having an "inner stride" greater than 1,
>> so yes "inner stride" is an important notion.
>
> Ok, now I do understand the issue.
>
>> To make things clearer, perhaps we could borrow the terminology of BLAS:
>> - "leading dimension" for matrices only (aka outer stride)
>> - "increment" for vectors only (aka inner stride).
>
> Since we already bound ourselves to rows() and cols(), yet another
> option would be something like rowStepSize() and colStepSize() or just
> stepSize() for vectors (similar to rows()/cols() and size()). For
> 'leading dimension', I do have right away to think about what it
> means. Is it the dimension with the fastest or slowest running index?
> The same holds for inner and outer. In case I have a for-loop over a
> 2D entity, there is a notion for inner and outer but nothing keeps me
> from changing the loop order. Here, you are assuming that everybody
> agrees that the inner loop is the one processing elements being
> closest in memory.

Let me recall that this stride information has two use cases:
1 - to allow users to directly deal with the underlying data, for
instance to interface with BLAS or LAPACK or any other lib,
2 - to directly map raw data.
In both cases we are talking about very low level aspects, where the
stride is only used to describe the memory layout. So here what we
really need is the "leading dimension" and or the "increment".
Otherwise we would have to write code such as:
ld = if(m is row major) m.colStepSize() else m.rowStepSize();....
Same for Map where the user would have to provide redundant information.


>
> By the way, do you plan to force strides to be multiples of
> sizeof(Scalar) (basically counting elements) or is the plan to have
> the strides in bytes?

Currently the stride represent a number of coefficients (as in
BLAS/LAPACK). Allowing an arbitrary number of bytes would very likely
lead to poor performance and would be more complicated to use.


gael