[Numpy-discussion] Trying out Numeric3

Peter Verveer verveer at embl.de
Fri Mar 25 15:16:06 CST 2005


On Mar 25, 2005, at 9:39 PM, Travis Oliphant wrote:

> Peter Verveer wrote:
>
>>>> This could be made a bit simpler by allowing only contiguous 
>>>> arrays, but then there would need to be a contiguous flag.
>>>
>>>
>>> I'm thinking just contiguous arrays would be passed.  While Numeric 
>>> does support the multi-segment buffer interface.  I doubt extension 
>>> writers want to try and understand how to deal with it.    I think 
>>> it would be too much of a burden to other extensions if the array 
>>> they saw was not contiguous.    Even internal to Numeric, 
>>> discontiguous arrays are made contiguous all the time (although the 
>>> new iterator in Numeric3 makes it much easier for a programmer to 
>>> deal with discontiguous arrays).
>>
>>
>> It think it would be a real shame not to support non-contiguous data. 
>> It would be great if such a byte object could be used instead of 
>> Numeric/numarray arrays when writing extensions. Then I could write C 
>> extensions that could be made available very easily/efficiently to 
>> any package supporting it without having to worry about the specific 
>> C api of those packages. If only contiguous byte objects are 
>> supported that byte object is not a good option anymore for 
>> implementing extensions for Numeric unless I am prepared to live with 
>> a lot of copying of non-contiguous arrays.
>
>
> How would you support "non-contiguous" data with the bytes object?   
> Or do you mean just passing the strides information around as meta 
> data?   With the bytes object pointing to the start?

Exactly.

> The latter would not be hard to support (it's just a matter of 
> defining an additional piece of meta information and making people 
> aware of it)  but not every extension writer would try and deal with 
> that, I'm sure.  But, that would be o.k.

There needs to be a way to treat such objects as contiguous for people 
who do not want to deal with strides, which means copying data if 
needed. It would need some thought to make that transparent, and the 
question is if it is worth the trouble.

I have not really followed the discussion about the byte object, and 
maybe I have got the wrong idea about its function. But if you see it 
as a generic data model for homogeneous array data, then it would 
provide a basis for writing C extensions that could work with different 
packages. For example to write a C extension of image processing 
routines  that would work with both Numeric arrays and PIL images.

Peter





More information about the Numpy-discussion mailing list