[Numpy-discussion] numarray, Numeric and 64-bit platforms

Francesc Altet faltet at carabos.com
Wed Apr 27 05:40:35 CDT 2005


A Dimarts 26 Abril 2005 22:55, Todd Miller va escriure:
> > The problem is that, for 32-bit platforms, na.typecode() == 'i' as it
> > should be, but for 64-bit platforms na.typecode() == 'N' that is not a
> > valid type in Numeric. I guess that na.typecode() should be mapped to
> > 'l' in 64-bit platforms so that Numeric can recognize the Int64
> > correctly.
>
> I agree that since the typecode() method exists for backward
> compatibility,  returning 'N' rather than 'l' on an LP64 platform can be
> considered a bug.   However,  there are two problems I see:
>
> 1. Returning 'l' doesn't handle the case of converting a numarray Int64
> array on a 32-bit platform.   AFIK, there is no typecode that will work
> for that case.  So,  we're only getting a partial solution.

One can always do a separate case for 64-bit platforms. This solution
is already used in Lib/numerictypes.py

> 2. numarray uses typecodes internally to encode type signatures.  There,
> platform-independent typecodes are useful and making this change will
> add confusion.

Well, this is the root of the problem for 'l' (long int) types, that
their meaning depends on the platform.

Anyway, I've tried with the next patch, and everything seems to work
well (i.e. it's done what it is itended):

--------------------------------------------------------------
--- Lib/numerictypes.py         Wed Apr 27 07:13:08 2005
+++ Lib/numerictypes.py.modif   Wed Apr 27 07:21:48 2005
@@ -389,7 +389,11 @@
 # at code generation / installation time.
 from codegenerator.ufunccode import typecode
 for tname, tcode in typecode.items():
-    typecode[ eval(tname)] = tcode
+    if tname == "Int64" and numinclude.LP64:
+        typecode[ eval(tname)] = 'l'
+    else:
+        typecode[ eval(tname)] = tcode
+

 if numinclude.hasUInt64:
     _MaximumType = {
---------------------------------------------------------------

With that, we have on 64-bit platforms:

>>> import Numeric
>>> Num=Numeric.array((3,),typecode='l')
>>> import numarray
>>> na=numarray.array(Num,typecode=Num.typecode())
>>> Numeric.array(na,typecode=na.typecode())
array([3])
>>> Numeric.array(na,typecode=na.typecode()).typecode()
'l'

and on 32-bit:

>>> Num=Numeric.array((3,),typecode='l')
>>> na=numarray.array(Num,typecode=Num.typecode())
>>> Numeric.array(na,typecode=na.typecode())
array([3],'i')
>>> Numeric.array(na,typecode=na.typecode()).typecode()
'i'

Which should be the correct behaviour.

> I think we may be butting up against the absolute/relative type
> definition problem.  Comments?

That may add some confusion, but if we want to be consistent with the
'l' (long int) meaning for different platforms, I think the suggested
patch (or other more elegant) is the way to go, IMHO.

Cheers,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"





More information about the Numpy-discussion mailing list