Travis Oliphant wrote: > Neal Becker wrote: >> I believe we are converging, and this is pretty much the same design as I >> advocated. It is similar to boost::ublas. >> > I'm grateful to hear that. It is nice when ideas come from several > different corners. >> Storage is one concept. >> >> Interpretation of the storage is another concept. >> >> Numpy is a combination of a storage and interpretation. >> >> Storage could be dense or sparse. Allocated in various ways. Sparse can >> be implemented in different ways. >> >> Interpretation can be 1-d, 2-d. Zero-based, non-zero based. Also there >> is question of ownership (slices). >> > > How do we extend the buffer interface then? Do we have one API that > allows sharing of storage and another that handles sharing of > interpretation? > > How much detail should be in the interface regarding storage detail. > Is there a possibility of having at least a few storage models > "shareable" so that memory can be shared by others that view the data in > the same way? >
How about: 1. A memory concept, of which buffer is an example. 2. A view concept. 3. A variety of common concrete types composing 1+2. So then, how do we use buffer in this scheme? I'm thinking that buffer isn't really the best thing to build on - but within this scheme buffer is a kind of memory (assuming it provides/could_be_made_to_provide the required interface). The view is not part of buffer, (as was proposed) but a separate piece. Still, I agree that we want a commonly used array object that includes both the memory and the view. I propose that we build it out of these more generic pieces, but also provide commonly used compositions of these pieces. I think this satisfies the desire for a self-describing array component, while allowing more flexibility and serving a wider usage. _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
