[SciPy-dev] Some suggestions for scipy_core

[Francesc Altet]

A Dilluns 02 Gener 2006 04:34, Travis E. Oliphant va escriure:
> > In [98]: scicore.typeDict['UInt16']
> > -------------------------------------------------------------------------
> >-- exceptions.KeyError                                  Traceback (most
> > recent call last)
> >
> > /home/faltet/python.nobackup/scipy_core/<console>
> >
> > KeyError: 'UInt16'
> >
> This is a mistake.  Uint16 should *be* UInt16.   That is one of the big
> purposes of typeDict (compatibility with numarray).

Good!

> > 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'.
>
> Sounds fine on the Bool.   But, note that unlike in numarray, the
> lower-case types are actual Python type objects.  The capitalized names
> are just string typecodes.   Also, ComplexXXX uses the old (bit-width of
> the float) convention for backwards compatibility, whereas the new
> complexXXX names use item-bit-width convention.

Mmm, I'm afraid that you added 'bool' but forgot about 'Bool'.

Also, ComplexXXX seems to follow item-bit-width convention instead of
numarray convention. Although I'm a bit hesitant on this regard in the
sense that having a 'complex64' equivalent to 'Complex32' can be a
source of confusion. For the sake of consistency, I'd advocate to let
things as they are now, i.e. 'Complex64' --> 'complex64' and
'Complex128' --> 'complex128'. I know that this violates the numarray
convention, but consistency should always be a must.

Perhaps a possible solution would be to define another dictionary just
for numarray mappings. So, we can have typeDict with the new types
defined in scipy_core and, say, typeDictNA that contains the types
defined in numarray. I think this would be a good way to avoid
unnecessary confusions and to simplify the already cluttered typeDict.
What others think?

> > 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?)
>
> Because it's an actual type object.  I think we could disable the tp_new
> method of the type.  Curently, this allows you do say int32([1,2,3,4])
> to construct an array.

Having the possibility to create arrays with int32([1,2,3,4]) sounds
appealing indeed. However, I wonder if you are providing too much
functionality to the dtype object. For me, it should just be a
container for the type of the data, but allowing it to be also a
factory for arrays may be confusing. This object could also define
some methods to write the different string representations for dtype.
For example dtype.char() will be equivalent to .dtypechar() defined in
ndarray object. In the same way, dtype.str() would be equivalent to
.dtypestr and dtype.descr() would be equivalent to .dtypedescr().

Maybe unrelated with this discussion, but important anyway because of
the (supposedly) large userbase that ipython have is the fact that
ipython will call the __call__() function for the object, if it founds
it. This makes things worse for the (ipython) user that wants just to
print the value of the dtype object.

So, my opinion on this subject is that dtype should just be a
container for information, and not a factory, and that __call__ should
be disabled on it (it is no longer necessary in this scenario). You
may add different intxx(), floatxx()... factories, but having array()
I think that would be more than enough.

> > In [118]: str(a.dtype)
> > Out[118]: "<type 'int32_arrtype'>"
> >
> > In [121]: repr(a.dtype)
> > Out[121]: "<type 'int32_arrtype'>"
>
> This would require creating a new metaclass because a.dtype is a
> typeobject and so prints using the standard type object printing.  We
> would have to inherit from the typeobject to change that standard.
>
> I think rather than shield people from the idea that dtype is an actual
> typeobject (which changing the printing would do) we should emphaize
> that fact.

I see your point. However, for better numarray interaction, I would
like to have a mean for a direct translation between
numarray<-->scipy_core types. For example, given a dtype like <type
'int32_arrtype'>, I'd like to be able to have a direct map into
numarray type (I think this is not possible now, is it?). In fact,
this is another point in favor of defining a new typeDictNA (or maybe
typeNA, for short), with keys for mapping the types in both senses.
For example:

{<type 'int8_arrtype'>: 'Int8', <type 'int16_arrtype'>: 'Int16',...
 'b': 'Int8', 'h': 'Int16', ...  # For shorter char keys
 'i1': 'Int8', 'i2': 'Int16', ...  # For string convention keys
 'Int8': 'b', 'Int16': 'h', ...} # The reverse mapping
 
Maybe this is too specific to my needs, but I'm sure that this can
facilitate the migration from numarray to scipy_core to other people
as well.

Finally, I have yet another (the last one, at least for today ;-)
question about scipy_core:

In [35]: print scicore.typeDict['I'], scicore.typeDict['L']
<type 'uint32_arrtype'> <type 'uint32_arrtype'>

In [36]: scicore.typeDict['I'] == scicore.typeDict['L']
Out[36]: False

The same goes for:

In [38]: print scicore.typeDict['i'], scicore.typeDict['l']
<type 'int32_arrtype'> <type 'int32_arrtype'>

In [39]: print scicore.typeDict['i'] == scicore.typeDict['l']
False

Is this consistent?. I would say no (I'm on a 32-bit platform).

Cheers,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"