Re: [Numpy-discussion] PEP 209: Multi-dimensional Arrays

[<ro...@ho...>]

>>>>> "PB" == Paul Barrett <Ba...@st...> writes:


 PB> .size (in bytes): e.g. 4, 8, etc.
 >> >> "element size?"

 PB> How about item_size?

OK.

 >>  No, it is not what I meant. Reading your answer I'd say that I
 >> wouldn't see the need for an Array. We only need a data buffer and
 >> an ArrayView. If there are two parts of the functionality, it is
 >> much cleaner to make the cut in an orthogonal way.


 PB> I just don't see what you are getting at here!  What attributes
 PB> does your Array have, if it doesn't have a shape or type?

A piece of memory. It needs nothing more. A buffer[1]. You'd always
need an ArrayView.  The Arrayview contains information like
dimensions, strides, data type, endianness.

Making a new _view_ would consist of making a new ArrayView, and pointing
its data object to the same data array. 

Making a new _copy_ would consist of making a new ArrayView, and
marking the "copy-on-write" features (however that needs to be
implemented, I have never done that. Does it involve weak
references?).

Different Views on the same data can even have different data types:
e.g. character and byte, or even floating point and integer (I am
a happy user of the fortran EQUIVALENCE statement that way too).

The speed up by re-use of temporary arrays becomes very easy this way
too: one can even re-use a floating point data array as integer result
if the reference count of both the data array and its (only) view is
one.

[1] Could the python buffer interface be used as a pre-existing
    implementation here? Would that make it possible to implement
    Array.append()? I don't always know beforehand how large my
    numeric arrays will become.

Rob

-- 
=====   ro...@ho...          http://www.hooft.net/people/rob/  =====
=====   R&D, Nonius BV, Delft  http://www.nonius.nl/             =====
===== PGPid 0xFA19277D ========================== Use Linux! =========