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? Glen
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
On 6/28/06, Robert Kern <robert.kern@gmail.com> wrote:
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:
Well, an easy way to make all those poke their ugly heads in a hurry would be to remove line 32 in scipy's init: longs[Lib]> grep -n oldnum *py __init__.py:31:import numpy.oldnumeric as _num __init__.py:32:from numpy.oldnumeric import * If we really want to push for the new api, I think it's fair to change those two lines by simply from numpy import oldnumeric so that scipy also exposes oldnumeric, and let all deprecated names be hidden there. I just tried this change: Index: __init__.py =================================================================== --- __init__.py (revision 2012) +++ __init__.py (working copy) @@ -29,9 +29,8 @@ # Import numpy symbols to scipy name space import numpy.oldnumeric as _num -from numpy.oldnumeric import * -del lib -del linalg +from numpy import oldnumeric + __all__ += _num.__all__ __doc__ += """ Contents and scipy's test suite still passes (modulo the test_cobyla thingie Nils is currently fixing, which is not related to this). Should I apply this patch, so we push the cleaned-up API even a bit harder? Cheers, f
On Wed, 28 Jun 2006 11:22:38 -0600 "Fernando Perez" <fperez.net@gmail.com> wrote:
On 6/28/06, Robert Kern <robert.kern@gmail.com> wrote:
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:
Well, an easy way to make all those poke their ugly heads in a hurry would be to remove line 32 in scipy's init:
longs[Lib]> grep -n oldnum *py __init__.py:31:import numpy.oldnumeric as _num __init__.py:32:from numpy.oldnumeric import *
If we really want to push for the new api, I think it's fair to change those two lines by simply
from numpy import oldnumeric
so that scipy also exposes oldnumeric, and let all deprecated names be hidden there.
I just tried this change:
Index: __init__.py =================================================================== --- __init__.py (revision 2012) +++ __init__.py (working copy) @@ -29,9 +29,8 @@
# Import numpy symbols to scipy name space import numpy.oldnumeric as _num -from numpy.oldnumeric import * -del lib -del linalg +from numpy import oldnumeric + __all__ += _num.__all__ __doc__ += """ Contents
and scipy's test suite still passes (modulo the test_cobyla thingie Nils is currently fixing, which is not related to this).
Should I apply this patch, so we push the cleaned-up API even a bit harder?
Yes please. I think all the modules that still use the oldnumeric names actually import numpy.oldnumeric themselves. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
On 6/28/06, David M. Cooke <cookedm@physics.mcmaster.ca> wrote:
On Wed, 28 Jun 2006 11:22:38 -0600 "Fernando Perez" <fperez.net@gmail.com> wrote:
Should I apply this patch, so we push the cleaned-up API even a bit harder?
Yes please. I think all the modules that still use the oldnumeric names actually import numpy.oldnumeric themselves.
Done, r2017. I also committed the simple one-liner: Index: weave/inline_tools.py =================================================================== --- weave/inline_tools.py (revision 2016) +++ weave/inline_tools.py (working copy) @@ -402,7 +402,7 @@ def compile_function(code,arg_names,local_dict,global_dict, module_dir, compiler='', - verbose = 0, + verbose = 1, support_code = None, headers = [], customize = None, from a discussion we had a few weeks ago, I'd forgotten to put it in. I did it as a separate patch (r 2018) so it can be reverted separately if anyone objects. Cheers, f
participants (4)
-
David M. Cooke -
Fernando Perez -
Glen W. Mabey -
Robert Kern