[Numpy-discussion] UInt64 is not supported on 64-bit architecture?
falted at openlc.org
Tue Mar 18 10:53:32 CST 2003
A Dimarts 18 Març 2003 18:24, Todd Miller va escriure:
> That's great to hear! Incidentally, you should probably also set LP64
> to 1. That asserts that a Python integer (a C long) is 64-bits and
> makes the default array integer type Int64 rather than Int32. I don't
> know anything about SGI, but you can determine if LP64 is appropriate
> by looking at sys.maxint: 2-billionish is 32-bit, 9-gazillionish is
Well, to say the truth, I've already tested that, but it gave me some weird
errors with the Numeric compatibility tests included in PyTables. In
particular, it seems to make a difference between the "l" (long) and "i"
(int) typecodes, that make the tests to fail (maybe I should investigate
this more, but I'm short of time lately).
Besides, my python on IRIX seems to not support well the 64-bits integers:
nut 432$ python
Python 2.2.2 (#2, Nov 19 2002, 18:46:18)
[GCC 2.95.2 19991024 (release)] on irix646
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
which is the same as an 32-bit machine.
I think this is because I've compiled python with gcc 2.95.2 and it doesn't
support 64-bit integers. From the gcc man pages:
-mcpu=cpu type -mips2 -mips3 -mint64 -mlong64
-mlonglong128 -mmips-as -mgas -mrnames -mno-rnames
-mgpopt -mno-gpopt -mstats -mno-stats -mmemcpy
-mno-memcpy -mno-mips-tfile -mmips-tfile
-msoft-float -mhard-float -mabicalls -mno-abicalls
-mhalf-pic -mno-half-pic -G num -nocpp
but later you can read:
These options don't work at present.
So it seems like if could be dangerous to force the default integer types to
But anyway, this is most probably a limitation of GNU gcc than a flaw on
IRIX. I could test with the MIPSpro C compiler, but I've no time rigth now.
More information about the Numpy-discussion