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