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

Todd Miller jmiller at stsci.edu
Wed Apr 27 08:36:09 CDT 2005


On Wed, 2005-04-27 at 08:32, Francesc Altet wrote:
> 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

True.  I'm just pointing out that doing this is still "half broken".  On
the other hand,  it is also "half fixed".


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

My point was that if you have a numarray Int64 array,  there's nothing
in 32-bit Numeric to convert it to.  Round tripping from
Numeric-to-numarray works,  but not from numarray-to-Numeric.  In this
case,  I think "half-fixed" still has some merit,  I just wanted it to
be clear what we're not doing.

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

I logged this on Source Forge and will get something in for numarray-1.4
so that the typecode() method gives a workable answer on LP64. 
Intersted parties should stick to using the typecode() method rather
than any of numarray's typecode related mappings.

Cheers,
Todd







More information about the Numpy-discussion mailing list