<br><br><div><span class="gmail_quote">On 1/5/07, <b class="gmail_sendername">Travis Oliphant</b> <<a href="mailto:oliphant@ee.byu.edu">oliphant@ee.byu.edu</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>><br>> On 1/5/07, *Stefan van der Walt* <<a href="mailto:stefan@sun.ac.za">stefan@sun.ac.za</a><br>> <mailto:<a href="mailto:stefan@sun.ac.za">stefan@sun.ac.za</a>>> wrote:
<br>><br>>     On Fri, Jan 05, 2007 at 09:38:49AM -0500, Neal Becker wrote:<br>>     >     Several extensions to Python utilize the buffer protocol to<br>>     share<br>>     >     the location of a data-buffer that is really an N-dimensional
<br>>     >     array.  However, there is no standard way to exchange the<br>>     >     additional N-dimensional array information so that the<br>>     data-buffer<br>>     >     is interpreted correctly.
<br>>     ><br>>     > I am questioning if this is the best concept.  It says that the<br>>     data-buffer<br>>     > will carry the information about it's interpretation as an<br>>     N-dimensional
<br>>     > array.<br>>     ><br>>     > I'm thinking that a buffer is just an interface to memory, and<br>>     that the<br>>     > interpretation as an array of n-dimensions, for example, is best
<br>>     left to<br>>     > the application.  I might want to at one time view the data as<br>>     > n-dimensional, but at another time as 1-dimensional, for example.<br>><br>>     You can always choose to ignore that information if you don't need it.
<br>>     On the other hand, if you *do* need it, how would you otherwise<br>>     interpret an N-dimensional array, given only a buffer?<br>><br>><br>> I think Neal is suggesting some object that basically does nothing but
<br>> hold a pointer(s) to memory. This memory can be used in various ways,<br>> one of which is to use it construct another type of object that<br>> provides a view with indices and such, i.e., an array. That way the
<br>> memory isn't tied to arrays and could concievable be used in other<br>> ways. The idea is analagous to the data/model/view paradigm. It is a<br>> bit cleaner than just ignoring the array parts.<br><br>Such an object would be useful.  I would submit that it is what the
<br>buffer object "should be"</blockquote><div><br>Yeah. The problem is that we have a buffer API, not a buffer object.<br></div><br>Chuck<br></div><br>