[Numpy-discussion] Learning "strides"

[Sasha]

On 2/2/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
> Sasha wrote:
> >
> Of course strides have always been there, they've just never been
> visible from Python.
>

I know that strides were always part of C-API, but I don't know if
they were exposed to python in numarray. If they were, there is
probably some history of use.  Can someone confirm or deny that?


> Allowing the user to set the strides may not be a good idea.  It was
> done largely so that the code that deals with misaligned data could be
> tested.

Presently settable strides attribute does not feel like an "experts
only" feature. (You've documented it in your book!)

>    However, it also allows you a lot of flexibility for
> interacting with arbitrary data-buffers that might be useful, so I'm
> inclined to allow it if the possible problems can be fixed.
>

This is a great feature and I can see it being used to explain
ndarrays to novices.  I don't think it should be regarded as "for
experts only."

> >
> >Looks like a bug.  PyArray_CheckStrides only checks for one end of the
> >buffer.
> >
> Right.  PyArray_CheckStrides needs to be better or we can't allow
> negative strides.
>
Please let me know if you plan to change PyArray_CheckStrides so that
we don't duplicate effort.

> >3.  "Fractional" strides:
> >I call "fractional" strides that are not a multiple of "itemsize".

> In dealing with an arbitrary data-buffer, I could see this as being
> useful, so I'm not sure if disallowing it is a good idea.

Can you suggest a use-case?  I cannot think of anything that cannot be
handled using a record-array view of the buffer.

>  Again,
> setting strides is not something that should be done by the average user
> so  I'm not as concerned about "forgetting" the units strides are in.
> If a user is going to be setting strides you have to assume they are
> being careful.
>
The problem is that many people (including myself) think that they
know what strides are when they come to numpy because they used
strides in other libraries (e.g. BLAS).
Most people expect element-based strides.  A footnote in your book
"Our definition of stride here is an element-based stride, while the
strides attribute returns a byte-based stride." also suggests that
element-based strides are more natural.

> A separate attribute called steps that uses element-sizes instead of
> byte-sizes is a possible idea.

Assuming strides attribute is not used except for testing, would you
object to renaming current byte-based strides to "byte_strides" and
implementing element-based "strides"?
I would even suggest "_byte_strides"  as a clearly "don't use it
unless you know what you are doing" name.