[Numpy-discussion] Latest Array-Interface PEP

Neal Becker ndbecker2 at gmail.com
Fri Jan 12 08:33:27 CST 2007


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.



More information about the Numpy-discussion mailing list