numpy-discussion

[Numpy-discussion] UInt64 is not supported on 64-bit architecture?

[Francesc A. <fa...@op...>]

Hi,

numarray seems to not support UInt64 types in 64-bit architecture. For
example, on SGI Origin 2000 with R12000 processors, I'm getting:

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)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File=20
"/scratch1/fernande/libs/lib/python2.2/site-packages/numarray/numarray.py=
",=20
line 959, in ones
    retarr =3D _fillarray(ndarray.product(shape), 1, 0, type)
  File=20
"/scratch1/fernande/libs/lib/python2.2/site-packages/numarray/numarray.py=
",=20
line 160, in _fillarray
    if outtype > ptype: # Hack for Int64/UInt64 on 32-bit platforms.
  File=20
"/scratch1/fernande/libs/lib/python2.2/site-packages/numarray/numerictype=
s.py",=20
line 112, in __cmp__
    return (genericTypeRank.index(self.name) -
ValueError: list.index(x): x not in list
>>>

while in my laptop (pentium IV, i.e. 32-bit), I've no problem with that:

Python 2.2.2 (#3, Dec 26 2002, 16:40:05)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numarray
>>> numarray.ones((3,), numarray.UInt64)
array([1, 1, 1], type=3DUInt64)
>>>

This is bizarre that a 64-bit machine does not support the UInt64 type wh=
ile
a 32-bit one do. I've been looking at the numarray code and that seems to=
 be
intentional, but I can't understand why.

Somebody can enlighten my mind? Thanks,

--=20
Francesc Alted

Re: [Numpy-discussion] UInt64 is not supported on 64-bit architecture?

[Francesc A. <fa...@op...>]

A Dimarts 18 Mar=E7 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 =3D=3D "osf1V5":
     EXTRA_COMPILE_ARGS.extend(["-ieee"])
     LP64, HAS_UINT64, HAS_FLOAT128 =3D 1, 1, 1
+elif sys.platform =3D=3D "irix646":
+    LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 1, 0
 elif sys.platform =3D=3D "linux2":
     LP64, HAS_UINT64, HAS_FLOAT128 =3D 0, 1, 0
 elif sys.platform =3D=3D "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=3DUInt64)
>>> ^D

Thanks for the pointer,

--=20
Francesc Alted

Re: [Numpy-discussion] UInt64 is not supported on 64-bit architecture?

[Todd M. <jm...@st...>]

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,
>

Re: [Numpy-discussion] UInt64 is not supported on 64-bit architecture?

[Francesc A. <fa...@op...>]

A Dimarts 18 Mar=E7 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 wei=
rd
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=3Dcpu 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 no=
w.

Regards,

--=20
Francesc Alted

Re: [Numpy-discussion] UInt64 is not supported on 64-bit architecture?

[Todd M. <jm...@st...>]

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