<br><br><div><span class="gmail_quote">On 1/11/07, <b class="gmail_sendername">David Cournapeau</b> <<a href="mailto:david@ar.media.kyoto-u.ac.jp">david@ar.media.kyoto-u.ac.jp</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Charles R Harris wrote:<br>><br>><br>> On 1/11/07, *David Cournapeau* <<a href="mailto:david@ar.media.kyoto-u.ac.jp">david@ar.media.kyoto-u.ac.jp</a><br>> <mailto:<a href="mailto:david@ar.media.kyoto-u.ac.jp">
david@ar.media.kyoto-u.ac.jp</a>>> wrote:<br>><br>>     Timothy Hochberg wrote:<br>>     ><br>>     ><br>>     > On 1/11/07, *Christopher Barker* <<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov
</a><br>>     <mailto:<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a>><br>>     > <mailto:<a href="mailto:Chris.Barker@noaa.gov">Chris.Barker@noaa.gov</a> <mailto:<a href="mailto:Chris.Barker@noaa.gov">
Chris.Barker@noaa.gov</a>>>><br>>     wrote:<br>>     ><br>>     > [CHOP]<br>>     ><br>>     ><br>>     >     I'd still like to know if anyone knows how to efficiently<br>>     loop through
<br>>     >     all the elements of a non-contiguous array in C.<br>>     ><br>>     ><br>>     > First, it's not that important if the array is contiguous for this<br>>     > sort of thing. What you really care about is whether it's
<br>>     > simply-strided (or maybe single-strided would be a better term).<br>>     > Anyway, the last dimension of the array can be strided without<br>>     making<br>>     > things more difficult. All you need to be able to do is to
<br>>     address the<br>>     > elements of the array as thedata[offset + stride*index].<br>>     I don't understand why we need to do thedata[offset + stride * index]<br>>     instead of thedata[index] when the data are aligned ? It looks like I
<br>>     seriously misunderstood the meaning of alignement...<br>><br>><br>> I think you are confusing aligned for contiguous. Aligned normally<br>> means the data occurs on natural address boundaries for the
<br>> architecture and item size, say multiples of 4 for 32 bit words on 32<br>> bit machines.<br>I understand that definition of alignment, but I thought it also implied<br>that the data buffer has an equal spacing between its elements, and this
<br>spacing is equal to the size of the type ?<br><br><br>> This contrasts with the case where a word is split across natural<br>> boundaries: some architectures support that with decreased<br>> performance, others don't. Then there are endianess issues, etc, etc.
<br>> Anyway, the easiest data to deal with is contiguous data where the<br>> data items lie one after the other in (virtual) memory. The next<br>> easiest is where the spacing between data elements is fixed,<br>
So does that mean you can have a numpy array of let's say 8 bytes<br>double, but that each item's address may be 16 bytes one from each other<br>(if we suppose alignment) ?</blockquote><div><br>Well, the common machines are 32 bit and 64 bit, so for instance extended precision (usually 80 bits) ends up as 96 bits (3*32) on the first and 128 (2*64) bits on the second, with the extra bits ignored. The items in c structures will often have empty spaces filling in between them unless specific compiler directives are invoked and the whole will be aligned on the appropriate boundary. For instance, on my machine
<br><br><span style="font-family: courier new,monospace;">struct bar {</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">    char a;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">    int  b;</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">};</span><br><br>is 8 bytes long because the int forces the whole too be aligned on a 4 byte boundary. I have seen 16 byte alignments for altivec (128 bits) on PPC. So on and so forth. It is all very achitecture dependent. But to answer you guestion, alignment is something that describes the location of a *single* item in memory, usually various numbers, but sometimes structures also. Contiguous describes the spacing between items.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There are three concepts here:<br>    1: address alignment: to be sure that data pointer is a multiple of
<br>the data type (a bit like buffer returned by posix_memalign).<br>    2: data "packing": for an array with elements of size d bytes, for a<br>given element, you get the next one by adding d bytes to the data pointer.
<br>    3: style of indexing, eg for a rank 4, what is the function (a, b,<br>c, d) -> i such as array->data[i] = array[a, b, c, d].<br><br>    So if I understand you correctly, contiguous is about points 2 and<br>3, and not 3 only as I first thought ?
</blockquote><div><br>2 and 3 are pretty much the same thing in c, but not in numpy. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 I am confused about the relation<br>between (in bytes) strides, contiguous and alignment... Because when I<br>read the pages 25 to 28 of the numpy ebook about contiguous memory<br>layout, we talk only about items indexing and the relationship between
<br>multi-dimensional numpy indexing and one dimension indexing in the<br>actual data buffer (point 3).<br>    I thought all numpy arrays were packed...</blockquote><div><br>The underlying data may be contiguous, but the view is not necessarily so. Transpose, for instance, just changes the view, not the storage, likewise, a[::2] returns a view that skips over every other item. Since x = a[::2] is a valid numpy array sharing memory with a, the items of x are not contiguous.
<br><br>Chuck<br></div><br></div><br>