Re: [Numpy-discussion] UInt64 is not supported on 64-bit architecture?
A Dimarts 18 Març 2003 16:47, Todd Miller va escriure:
It may be a fairly simple matter of an unsupported platform; I don't have access to the SGI machine you're dealing with. The default block in numarray's setup.py compiles for 32-bit without support for UInt64. Add a case for SGI and you may be done. If so, please send a patch.
I see. I'm attaching the patch for IRIX 6.5 (IRIX64 nut 6.5 07121149 IP27): --- setup.py.orig Tue Mar 18 17:24:40 2003 +++ setup.py.irix Tue Mar 18 17:42:37 2003 @@ -32,6 +32,8 @@ if sys.platform == "osf1V5": EXTRA_COMPILE_ARGS.extend(["-ieee"]) LP64, HAS_UINT64, HAS_FLOAT128 = 1, 1, 1 +elif sys.platform == "irix646": + LP64, HAS_UINT64, HAS_FLOAT128 = 0, 1, 0 elif sys.platform == "linux2": LP64, HAS_UINT64, HAS_FLOAT128 = 0, 1, 0 elif sys.platform == "sunos5": I've only set the UInt64 support because I don't know if this platform supports floats of 128 bits and neither what LP64 exactly means. With that, numarray supports UInt64 arrays on IRIX perfectly: nut 435$ 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 numarray numarray.ones((3,), numarray.UInt64) array([1, 1, 1], type=UInt64) ^D
Thanks for the pointer, -- Francesc Alted
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. Todd Francesc Alted wrote:
A Dimarts 18 Març 2003 16:47, Todd Miller va escriure:
It may be a fairly simple matter of an unsupported platform; I don't have access to the SGI machine you're dealing with. The default block in numarray's setup.py compiles for 32-bit without support for UInt64. Add a case for SGI and you may be done. If so, please send a patch.
I see. I'm attaching the patch for IRIX 6.5 (IRIX64 nut 6.5 07121149 IP27):
--- setup.py.orig Tue Mar 18 17:24:40 2003 +++ setup.py.irix Tue Mar 18 17:42:37 2003 @@ -32,6 +32,8 @@ if sys.platform == "osf1V5": EXTRA_COMPILE_ARGS.extend(["-ieee"]) LP64, HAS_UINT64, HAS_FLOAT128 = 1, 1, 1 +elif sys.platform == "irix646": + LP64, HAS_UINT64, HAS_FLOAT128 = 0, 1, 0 elif sys.platform == "linux2": LP64, HAS_UINT64, HAS_FLOAT128 = 0, 1, 0 elif sys.platform == "sunos5":
I've only set the UInt64 support because I don't know if this platform supports floats of 128 bits and neither what LP64 exactly means.
With that, numarray supports UInt64 arrays on IRIX perfectly:
nut 435$ 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 numarray numarray.ones((3,), numarray.UInt64)
array([1, 1, 1], type=UInt64)
^D
Thanks for the pointer,
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
Francesc Alted wrote:
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).
That sounds consistent with my understanding of LP64. C longs and pointers are 64-bit, while C ints remain 32-bit. Hence, for LP64, 'i' and 'l' should be different. That is not to say numarray has it's act totally together here; LP64 is rather confusing, as is the fact that a Python Int is actually a C long. For now, I'll just apply your patch as-is.
Regards, Todd
participants (2)
-
Francesc Alted -
Todd Miller