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