Maybe I'm becoming a bit tedious with this, but if you look at:
>>> import numerictypes
>>> numerictypes.typecode
{Complex64: 'D', Int32: 'l', UInt16: 's', Complex32: 'F', Float64: 'd',
UInt8: 'b', Int16: 's', Float32: 'f', Int8: '1'}
you can find some incongruencies that lead to weird things like:
>>> array([1,2], Int16).typecode()
's'
>>> array([1,2], UInt16).typecode()
's' # --> same as Int16!
>>> array([1,2], Int64).typecode()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/local/lib/python2.2/site-packages/numarray/numarray.py", lin=
e=20
730, in typecode
return numerictypes.typecode[self._type]
KeyError: numarray type: Int64
>>> array([1,2], UInt64).typecode()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/local/lib/python2.2/site-packages/numarray/numarray.py", lin=
e=20
730, in typecode
return numerictypes.typecode[self._type]
KeyError: numarray type: UInt64
Also, 'l' is used here to map Int32, while in recarray is used to map Boo=
lean.
Moreover, Numeric 22.0 introduced the equivalent of UInt16 and UInt32 typ=
es
as 'w' and 'u' respectively. But, again, 'u' is used in recarray as synon=
ym
of Uint8.
I think it's important to agree with a definitive set of charcodes and us=
e
them uniformly throughout numarray.
Suggestion: if recarray charcodes are not necessary to match the Numeric
ones, I propose that using the Python convention maybe a good idea.
Look at the table in:
http://www.python.org/doc/current/lib/module-struct.html.
--=20
Francesc Alted
|
