[Numpy-discussion] Performance of the array protocol

David M. Cooke cookedm at physics.mcmaster.ca
Tue Nov 1 13:02:06 CST 2005


Travis Oliphant <oliphant at ee.byu.edu> writes:

> David M. Cooke wrote:
>
>>"C
>>
>>I had posted an idea before:
>>
>>http://thread.gmane.org/gmane.comp.python.numeric.general/2159
>>
>>It would still be one attribute lookup, but then everything would be
>>C-based from there on.
>>
>>
> Thanks for reminding us of your idea again.   This is a very good idea, 
> that I think we could add.   My only question is should Py_LONG_LONG be 
> used or Py_intptr_t?   Since the array has to be in memory anyway there 
> does not seem any advantage to using Py_LONG_LONG.

Ok, I see how that works. I probably wasn't aware of the existence of
Py_intptr_t at the time :-)

> I also think a flags member of the structure is useful along with a 
> typestr instead of typecode.

The point of a typecode instead of a typestr was to make it easy for
code to determine the type. Endianness would be part of the flags, and
the number of bytes for the type would be in itemsize.

> I would say the C-struct should look 
> like.  We could push to get something like this in Python core, I think, 
> so this Array_Interface header was available to everybody.
>
> typedef struct {
>    int nd;
>    char typekind;
>    int itemsize;
>    int flags;
>    Py_intptr_t *shape;
>    Py_intptr_t *strides;
>    Py_intptr_t offset;
>    void *data;
> } PyArray_Interface

If it's in the Python core, then this is fine. If we did it ourself as
an informal protocol (like the array interface spec), I'd still add
the version member as a sanity check.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca




More information about the Numpy-discussion mailing list