[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