[Numpy-discussion] Trying out Numeric3
oliphant at ee.byu.edu
Fri Mar 25 12:42:08 CST 2005
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? 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.
More information about the Numpy-discussion