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.