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.