[Numpy-discussion] numarray, Numeric and 64-bit platforms
Todd Miller
jmiller at stsci.edu
Wed Apr 27 08:36:09 EDT 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