Francesc Altet wrote:
Now, let's test the conversion for large objects, with data copy and without data copy.
I didn't consider that case but was thinking the semantics of the array interface would be "buffer-like" and therefore non-copying. So at the moment numarray *never* copies and completely ignores the non-sequence array() parameters for the "array interface" case.
For numarray-->Numeric:
t2=timeit.Timer("num=Numeric.array(na,copy=0)","import
Numeric;import numarray; na=numarray.arange(100000)")
t2.repeat(3,100)
[0.0025169849395751953, 0.0025219917297363281, 0.0024950504302978516]
t2_copy=timeit.Timer("num=Numeric.array(na,copy=1)","import
Numeric;import numarray; na=numarray.arange(100000)")
t2_copy.repeat(3,100)
[0.50105500221252441, 0.49400091171264648, 0.49266600608825684]
So it seems like if the data copy is taking place.
I agree and was to be able to verify this by making buffer()s out of the resulting arrays to examine their data addresses.
For Numeric-->numarray:
t4=timeit.Timer("na=numarray.array(num,copy=0)","import
Numeric;import numarray; num=Numeric.arange(100000)")
t4.repeat(3,100)
[0.0054900646209716797, 0.0044760704040527344, 0.0048201084136962891]
t4_copy=timeit.Timer("na=numarray.array(num,copy=1)","import
Numeric;importnumarray; num=Numeric.arange(100000)")
t4_copy.repeat(3,100)
[0.0063569545745849609, 0.004302978515625, 0.0042738914489746094]
Ooops! the times for conversion with copy and without copy are more or less the same. Perhaps the copy is not done? It seems so:
num=Numeric.arange(10) na=numarray.array(num,copy=0) na_copy=numarray.array(num,copy=1) na.info()
... data pointer: 0x08312280 (DEBUG ONLY)
na_copy.info()
... data pointer: 0x08312280 (DEBUG ONLY)
i.e. the same data pointer. So it seems that the Numeric-->numarray is not copying the data even in the case that we are asking to do that.
Yeah, the copy=X flag is totally ignored at the moment.
Other minor things (maybe this is just because you are in the middle of refactoring):
na._data
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
while I would expect:
na._data
<memory at 0x081e3618 with size:0x00000028 held by object 0x401f06a0 aliasing object 0x00000000>
Also:
This is actually correct I think. Since a Numeric array supports the buffer protocol, it can be used as a buffer. The "memory" output shown above is the output from one particular kind of buffer; i.e. it's the repr of numarray's memory object.
na
Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 930, in __repr__ return array_repr(self) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1660, in array_repr lst = arrayprint.array2string( File "/usr/lib/python2.4/site-packages/numarray/arrayprint.py", line 188, in array2string separator, prefix) File "/usr/lib/python2.4/site-packages/numarray/arrayprint.py", line 140, in _array2string data = _gen.ravel(a) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 918, in copy c = _gen.NDArray.copy(self) File "/usr/lib/python2.4/site-packages/numarray/generic.py", line 724, in copy arr._itemsize) TypeError: NA_maybeLongsFromIntTuple: must be a sequence of integers.
For some reason Numeric was returning None for __array_strides__ and hence this message. I fixed array() so that strides are not set when __array_strides__ returns None. With the added complexity of handling the shape, type, and copy parameters in array(), I'm now seeing performance like this from CVS: numarray-->Numeric array_if: [0.40103912353515625, 0.41119098663330078, 0.41148614883422852] numarray-->Numeric fromstring: [0.24139499664306641, 0.27034401893615723, 0.21657609939575195] Numeric-->numarray array_if: [0.81009912490844727, 0.79906082153320312, 0.74358081817626953] Numeric-->numarray buffer_if: [0.27320504188537598, 0.22041201591491699, 0.22667884826660156] Todd