[Numpy-discussion] Re: Trying out Numeric3
Travis Oliphant
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
>>>>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).
>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
>Also note
>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
>that.]
>
>
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.
-Travis
More information about the NumPy-Discussion
mailing list