[Numpy-discussion] fread codes versus numpy types (original) (raw)

Robert Kern robert.kern at gmail.com
Wed Jun 28 12:25:37 EDT 2006

Glen W. Mabey wrote:

Hello,

I see the following character codes defined in scipy (presumably) for use with scipy.io.fread() : In [20]:scipy.Complex Out[20]:'D' In [21]:scipy.Complex0 Out[21]:'D' In [22]:scipy.Complex128 Out[22]:'G' In [23]:scipy.Complex16 Out[23]:'F' In [24]:scipy.Complex32 Out[24]:'F' In [25]:scipy.Complex64 Out[25]:'D' In [26]:scipy.Complex8 Out[26]:'F' Then I see the following scalar types also defined: In [27]:scipy.complex64 Out[27]:<type 'complex64scalar'> In [28]:scipy.complex128 Out[28]:<type 'complex128scalar'> In [29]:scipy.complex256 Out[29]:<type 'complex256scalar'> which correspond to types that exist within the numpy module. These names seem to conflict in that (unless I misunderstand what's going on) scipy.complex64 actually occupies 64 bits of data (a 32-bit float for each of {real, imag}) whereas scipy.Complex64 looks like it occupies 128 bits of data (a 64-bit double for each of {real, imag}). Is there something I'm missing, or is this a naming inconsistency?

The Capitalized versions are actually old typecodes for backwards compatibility with Numeric. In recent development versions of numpy, they are no longer exposed except through the numpy.oldnumeric compatibility module. A decision was made for numpy to use the actual width of a type in its name instead of the width of its component parts (when it has parts).

Code in scipy which still requires actual string typecodes is a bug. Please report such cases on the Trac:

http://projects.scipy.org/scipy/scipy

-- Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

More information about the NumPy-Discussion mailing list