[Numpy-discussion] UInt64 is not supported on 64-bit architecture?
Francesc Alted
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
> 64-bit.
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
>>> sys.maxint
2147483647
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:
MIPS Options
-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:
-mint64
-mlong64
-mlonglong128
These options don't work at present.
So it seems like if could be dangerous to force the default integer types to
Int64.
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.
Regards,
--
Francesc Alted
More information about the Numpy-discussion
mailing list