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