[Numpy-discussion] "aligned" matrix / ctypes
Thu Apr 24 21:15:33 CDT 2008
The problem with alignment on 3 byte boundaries, is that 3 is a prime and
not a factor of the size of any common data type. (The only exception I
can think of is 24 bit RGB values.) So in general, the elements in an
array for which the first element is aligned on a 3 byte boundary, may or
may not not be 3-byte aligned.
Byte boundary alignment should thus be a bit intelligent. If the size of
the dtype is not divisable by the byte boundary, an exception should be
In practice, only alignment on 2-, 4- and perhaps 8-byte boundaries are
really required. Alignment on 2 byte boundaries should perhaps be NumPy's
default (over no alignment), as MMX and SSE extensions depend on it.
nVidia's CUDA also require alignment on 2 byte boundaries.
> On Thu, Apr 24, 2008 at 4:57 PM, Zachary Pincus <email@example.com>
>> The reason that one must slice before .view()ing to allow arbitrary
>> alignment is as follows. Imagine that we want rows of four 2-byte
>> shorts aligned to 3-byte boundaries. (Assume that we already have a
>> buffer that starts on a 3-byte boundary.) So we need an array that's 9
>> bytes wide by however many rows, and then we just want to use the
>> first eight bytes of row. If we slice first, we can get a strided
>> array that is eight bytes wide, and thus something that we can
>> interpret as four shorts. (That is, if .view() could handle strided
>> On the other hand, there's absolutely no way that we can .view()
>> before slicing, because our underlying array is 9 bytes wide, and you
>> can't look at 9 bytes as any integral number of 2-byte shorts.
>> So .view() should properly fail, and thus we can't get to the slicing.
> Yes, you are right, sorry.
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
> Numpy-discussion mailing list
More information about the Numpy-discussion