[Numpy-discussion] Re: Trying out Numeric3
oliphant at ee.byu.edu
Tue Mar 22 23:14:44 EST 2005
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
>Why not use Py_intptr_t? It's defined by the Python C API already (in
Sounds good to me. I wasn't aware of it (intp or intptr is shorter
>An array of longs would seem to be the best solution. On the two
>64-bit platforms I have access to (an Athlon 64 and some Alphas),
>sizeof(long) == 8, while my two 32-bit platforms (Intel x86 and
>PowerPC) have sizeof(long) == 4.
I thought about this, but what about the MS Window compilers where long
is still 4 byte (even on a 64-bit system), so that long long is the
size of a pointer on that system. I just think we should just create
an integer that will be big enough and start using it.
>For comparison, here's a list of sizes for various platforms
> 32-bit 32-bit 64-bit 64-bit
> x86 PPC Athlon64 Alpha
> (Linux) (OS X) (Linux) (Tru64)
>char 1 1 1 1
>short 2 2 2 2
>int 4 4 4 4
>long 4 4 8 8
>long long 8 8 8 8
>size_t 4 4 8 8
>float 4 4 4 4
>double 8 8 8 8
>long double 12 8 16 16
>void * 4 4 8 8
>function pointer 4 4 8 8
Nice table, thanks...
>Note the three different sizes of long double (oh, fun).
Yeah, I know, I figure people who use long doubles will
>that size_t (which is the return type of sizeof()) is not int in
>general (although lots of programs treat it like that).
>Using long for the dimensions also means that converting to and from
>Python ints for indices is transparent, and won't fail, as Python ints
>are C longs. This is the cause of several of the 64-bit bugs I fixed
>in the latest Numeric release (23.8).
The conversion code has been updated so that it won't fail if the sizes
are actually the same for your platform.
>[I'd help with Numeric3, but not until it compiles with fewer than
>several hundred warnings -- I *really* don't want to wade through all
Do the warnings really worry you that much? Most are insignificant.
You could help implement a method or two pretty easily. Or help with
the ufunc module.
More information about the NumPy-Discussion