[Numpy-discussion] PEP 209: Multi-dimensional Arrays
Rob W. W. Hooft
rob at hooft.net
Fri Feb 16 04:18:11 EST 2001
>>>>> "PB" == Paul Barrett <Barrett at stsci.edu> 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
--
===== rob at hooft.net http://www.hooft.net/people/rob/ =====
===== R&D, Nonius BV, Delft http://www.nonius.nl/ =====
===== PGPid 0xFA19277D ========================== Use Linux! =========
More information about the NumPy-Discussion
mailing list