[Numpy-discussion] Re: Trying out Numeric3

Travis Oliphant oliphant at ee.byu.edu
Wed Mar 23 11:41:28 CST 2005


David M. Cooke wrote:

>On Wed, Mar 23, 2005 at 12:11:44AM -0700, Travis Oliphant wrote:
>  
>
>>David M. Cooke wrote:
>>    
>>
>>>Travis Oliphant <oliphant at ee.byu.edu> writes:
>>>      
>>>
>>>>Michiel Jan Laurens de Hoon wrote:
>>>>        
>>>>
>>>>>Travis Oliphant wrote:
>>>>>          
>>>>>
>>>>>>Michiel Jan Laurens de Hoon wrote:
>>>>>>            
>>>>>>
>>>>>>>Another warning was that PyArrayObject's "dimensions" doesn't seem
>>>>>>>to be an int array any more.
>>>>>>>              
>>>>>>>
>>>>>>Yes.   To allow for dimensions that are bigger than 32-bits,
>>>>>>dimensions and strides are (intp *).  intp is a signed integer with
>>>>>>sizeof(intp) == sizeof(void *).  On 32-bit systems, the warning
>>>>>>will not cause problems.  We could worry about fixing it by
>>>>>>typedefing intp to int (instead of the current long for 32-bit
>>>>>>systems).
>>>>>>            
>>>>>>
>>>Why not use Py_intptr_t? It's defined by the Python C API already (in
>>>pyport.h).
>>>      
>>>
>>Sounds good to me.  I wasn't aware of it (intp or intptr is shorter 
>>though).
>>    
>>
>
>Some reasons not to use those two:
>1) intp is too short for an API. The user might be using it already.
>2) the C99 type for this is intptr_t. Py_intptr_t is defined to be
>   the same thing.
>
>But let's step back a moment: PyArrayObject is defined like this:
>
>typedef struct PyArrayObject {
>    PyObject_HEAD
>    char *data;
>    int nd;
>    intp *dimensions;
>    intp *strides;
>    ...
>
>Thinking about it, I would say that dimensions should have the type of
>size_t *. size_t is the unsigned integer type used to represent the
>sizes of objects (it's the type of the result of sizeof()). Thus, it's
>guaranteed that an element of size_t should be large enough to contain
>any number that we could use as an array dimension. size_t is also
>unsigned
>  
>
Because axis arguments can be negative it would require a lot of changes 
to check for typing to make dimensions unsigned.  It's just easier to 
make them signed.   So, what is the signed equivalent?  Is ssize_t 
available everywhere?

>Also, since the elements of strides are byte offsets into the array,
>strides should be of type ptrdiff_t *. The elements are used by adding
>them to a pointer.
>  
>
Is this an available type on all systems?  What does it mean?

>Is there a good reason why data is not of type void *? If it's char *,
>it's quite easy to make the mistake of using data[0], which is probably
>*not* what you want. With void *, you would have to cast it, as you
>should be doing anyways, or else the compiler complains. Also, assigning
>to the right pointer, like double *A = array->data, doesn't need
>casts like it does with data being a char *. In Numeric, char * is
>probably a holdover when Numeric had to compile with K&R-style C. But,
>we know we have ANSI C89 ('cause that's what Python requires).
>  
>
Only real reason is backward compatibility.  I have no problem with 
making it void *.

>So I figure it should look like this:
>
>typedef struct PyArrayObject {
>    PyObject_HEAD
>    void *data;
>    int nd;
>    size_t *dimensions;
>    ptrdiff_t *strides;
>    ...
>
>I've really started to appreciate size_t when trying to make programs
>work correctly on my 64-bit machine :-) It's not just another pretty
>face.
>
>  
>
Good suggestions?  Any other comments.

>They really obscure significant warnings, though. And most look like
>they can be dealt with. Right now, it doesn't compile for me.
>
>I'll just list a few general cases:
>- arrayobject.h redefines ushort, uint, ulong (they're defined in
>  sys/types.h already for legacy reasons)
>  
>
I don't think they are defined on all systems (I don't get a warning on 
mysystem).   This is another thing configure needs to check if we are 
really concerned about the warnings.

>- functions taking no arguments should be defined like
>void function(void)
>not
>void function()
>  
>
Ah, thanks for that!

>I might get some time to track some down, but it's limited also :-)
>
>  
>
The errors right now are mainly due to the fact that I'm adding the new 
methods (and some functions things are left undefined).   I have not 
compiled the code for several days.  Adding methods is an easy thing 
that most anyone could help with.  The help would be appreciated.

-Travis










More information about the Numpy-discussion mailing list