<br><br><div><span class="gmail_quote">On 8/8/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>> Anne,<br>><br>> On 8/8/07, *Anne Archibald* <<a href="mailto:peridot.faceted@gmail.com">peridot.faceted@gmail.com</a><br>> <mailto:<a href="mailto:peridot.faceted@gmail.com">
peridot.faceted@gmail.com</a>>> wrote:<br>><br>>     On 08/08/2007, Charles R Harris <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a><br>>     <mailto:<a href="mailto:charlesr.harris@gmail.com">
charlesr.harris@gmail.com</a>>> wrote:<br>>     ><br>>     ><br>>     > On 8/8/07, Anne Archibald <<a href="mailto:peridot.faceted@gmail.com">peridot.faceted@gmail.com</a><br>>     <mailto:
<a href="mailto:peridot.faceted@gmail.com">peridot.faceted@gmail.com</a>>> wrote:<br>>     > > Oh. Well, it's not *terrible*; it gets you an aligned array.<br>>     But you<br>>     > > have to allocate the original array as a 1D byte array (to
<br>>     allow for<br>>     > > arbitrary realignments) and then align it, reshape it, and<br>>     reinterpret<br>>     > > it as a new type. Plus you're allocating an extra ndarray<br>>     structure,
<br>>     > > which will live as long as the new array does; this not only<br>>     wastes<br>>     > > even more memory than the portable alignment solutions, it<br>>     clogs up<br>>     > > python's garbage collector.
<br>>     ><br>>     > The ndarray structure doesn't take up much memory, it is the<br>>     data that is<br>>     > large and the data is shared between the original array and the<br>>     slice. Nor
<br>>     > does the data type of the slice need changing, one simply uses<br>>     the desired<br>>     > type to begin with, or at least a type of the right size so that<br>>     a view will<br>>     > do the job without copies. Nor do I see how the garbage
<br>>     collector will get<br>>     > clogged up, slices are a common feature of using numpy. The<br>>     slice method<br>>     > also has the advantage of being compiler and operating system<br>>     independent,
<br>>     > there is a reason Intel used that approach.<br>><br>I am not sure to understand which approach to which problem you are<br>talking about here ?<br><br>IMHO, the discussion is becoming a bit carried away. What I was
<br>suggesting is<br>    - being able to check whether a given data buffer is aligned to a<br>given alignment (easy)<br>    - being able to request an aligned data buffer: requires aligned<br>memory allocators, and some additions to the API for creating arrays.
<br><br>This all boils down to the following case: I have a C function which<br>requires N bytes aligned data, I want the numpy API to provide this<br>capability. I don't understand the discussion on doing it in python:
</blockquote><div><br>Well, what you want might be very easy to do in python, we just need to check the default alignments for doubles and floats for some of the other compilers, architectures, and OS's out there. On the other hand, you might not be able to request a c malloc that is aligned in a portable way without resorting to the same tricks as you do in python. So why not use python and get the reference counting and garbage collection along with it? What we want are doubles 8 byte aligned and floats 4 byte aligned. That seems to be the case with gcc, linux, and the Intel architecture. The idea is to create a slightly oversize array, then use a slice of the proper size that is 16 byte aligned.
<br><br>Chuck <br></div><br></div><br>