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", line 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", line 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 Boolean. Moreover, Numeric 22.0 introduced the equivalent of UInt16 and UInt32 types as 'w' and 'u' respectively. But, again, 'u' is used in recarray as synonym of Uint8. I think it's important to agree with a definitive set of charcodes and use 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. -- Francesc Alted