[Numpy-discussion] The array interface published
Michiel Jan Laurens de Hoon
mdehoon at ims.u-tokyo.ac.jp
Mon Apr 4 01:17:15 CDT 2005
Travis Oliphant wrote:
>> 1) To what degree will the new array interface look different to users
>> of the existing Numerical Python?
> Nothing will look different. For now there is nothing to "install" so
> the array interface is just something to expect from other objects.
> The only thing that would be different is in Numeric 24.0 (if a users
> were to call array(<someobj>) and <someobj> supported the array
> interface then Numeric could return an array (without copying data).
> Older versions of Numeric won't benefit from the interface but won't be
> harmed either.
Very nice. Thanks, Travis.
I'm not sure what you mean by "the array interface could become part of the
Python standard as early as Python 2.5", since there is nothing to install. Or
does this mean that Python's array will conform to the array interface?
Some comments on the array interface:
1) The "__array_shape__" method is identical to the existing "shape" method in
Numerical Python and numarray (except that "shape" does a little bit better
checking, but it can be added easily to "__array_shape__"). To avoid code
duplication, it might be better to keep that method. (and rename the other
methods for consistency, if desired).
2) The __array_datalen__ is introduced to get around the 32-bit int limitation
of len(). Another option is to fix len() in Python itself, so that it can return
integers larger than 32 bits. So we can avoid adding a new method.
3) Where do default values come from? Is it the responsability of the extension
module writer to find out if the array module implements e.g. __array_strides__,
and substitute the default values if it doesn't? If so, I have a slight
preference to make all methods required, since it's not a big effort to return
the defaults, and there will be more extension modules than array packages (or
so I hope).
Whereas the array interface certainly helps extension writers to create an
extension module that works with all array implementations, it also enables and
perhaps encourages the creation of different array modules, while our original
goal was to create a single array module that satisfies the needs of both
Numerical Python and numarray users. I still think such a solution would be
preferable. Inconsistencies other than the array interface (e.g. one implements
argmax(x) while another implements x.argmax()) may mean that an extension module
can work with one array implementation but not with another, even though they
both conform to the array interface. We may end up with several array packages
(we already have Numerical Python, numarray, and scipy), and extension modules
that work with one package and not with another. So in a sense, the array
interface is letting the genie out of the bottle.
But maybe such a single array package is not attainable given the different
needs of the different communities.
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
More information about the Numpy-discussion