[SciPy-dev] Some suggestions for scipy_core
Francesc Altet
faltet at carabos.com
Sun Jan 1 18:04:00 CST 2006
Hi,
I've started looking at giving suport of scipy_core objects into
PyTables. I begun by homogenous array (not chararrays or recarrays
yet), and discovered some issues that perhaps can be improved in
scipy_core:
1.- Is there any reason for this?
In [67]: type(scicore.array(3, dtype='D'))
Out[67]: <type 'scipy.ndarray'>
In [68]: type(scicore.array(3).astype('D'))
Out[68]: <type 'complex128_arrtype'> !!!!!!!!
However, astype() seems to work correctly with arrays:
In [69]: type(scicore.array([3], dtype='D'))
Out[69]: <type 'scipy.ndarray'>
In [70]: type(scicore.array([3]).astype('D'))
Out[70]: <type 'scipy.ndarray'>
2.- For the sake of compatibility with numarray, I'm wondering if you
can include entries in the typeDict dictionary that follows numarray
conventions.
In [98]: scicore.typeDict['UInt16']
---------------------------------------------------------------------------
exceptions.KeyError Traceback (most
recent call last)
/home/faltet/python.nobackup/scipy_core/<console>
KeyError: 'UInt16'
However, this exists:
In [99]: scicore.typeDict['Uint16']
Out[99]: <type 'uint16_arrtype'>
Better yet, would the change 'UintXX' --> 'UIntXX' possible? I also
like this because 1) is a standard (at least is what the users of
numarray are used to, so why invent yet another convention?) and 2) if
you want to obtain the unsigned version of a type, you just have to
write: 'U'+signed_type, and you are done.
Also, for numarray compatibility, could 'complexXXX' --> 'ComplexXXX'
be made? And add a 'Bool'? I know that a type 'Bool8' exists, but
perhaps 'Bool' can be added as an alias of 'Bool8'.
3.- Finally, I'd advocate to have a more handy string representation
for .dtype. Right now, one have:
In [117]: a.dtype
--------> a.dtype()
Out[117]: 0
(why dtype supports the call protocol? Is it really necessary?)
In [118]: str(a.dtype)
Out[118]: "<type 'int32_arrtype'>"
In [121]: repr(a.dtype)
Out[121]: "<type 'int32_arrtype'>"
I'd suggest that the string representation for dtype would follow the
numarray convention, so that str(a.dtype) would give 'Int32', 'UInt32'
and so on. This would enhance the interoperativity between numarray
and scipy_core (during the time they have to coexist). Also, having a
simple string representation for types may easy the type manipulation.
The repr(a.dtype) would be left as it is now.
Thanks and Happy New Year!
--
>0,0< Francesc Altet http://www.carabos.com/
V V Cárabos Coop. V. Enjoy Data
"-"
More information about the Scipy-dev
mailing list