Re: [Numpy-discussion] fread codes versus numpy types

[Robert K. <rob...@gm...>]

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