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

Todd Miller jmiller at stsci.edu
Tue Apr 26 13:57:14 CDT 2005


On Tue, 2005-04-26 at 13:42, Francesc Altet wrote:
> Hi,
> 
> I'm having problems converting numarray objects into Numeric in 64-bit
> platforms, and I think this is numarray fault, but I'm not completely
> sure. 
> 
> The problem can be easily visualized in an example (I'm using numarray
> 1.3.1 and Numeric 24.0b2). In a 32-bit platform (Intel32, Linux):
> 
> >>> Num=Numeric.array((3,),typecode='l')
> >>> na=numarray.array(Num,typecode=Num.typecode())
> >>> Numeric.array(na,typecode=na.typecode())
> array([3],'i')    # The conversion has finished correctly
> 
> In 64-bit platforms (AMD64, Linux):
> 
> >>> Num=Numeric.array((3,),typecode='l')
> >>> na=numarray.array(Num,typecode=Num.typecode())
> >>> Numeric.array(na,typecode=na.typecode())
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> TypeError: typecode argument must be a valid type.
> 
> 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.
> 
> Any suggestion?

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.

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

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

Todd





More information about the Numpy-discussion mailing list