[SciPy-dev] Some suggestions for scipy_core

Travis E. Oliphant oliphant.travis at ieee.org
Wed Jan 4 01:12:57 CST 2006

Francesc Altet wrote:
> I've made some progress for comparing datatypes of type 'i' and 'l'
> correctly. Right now, in 32-bit platforms, scipy_core gives:
> In [25]: a=scicore.arange(10,dtype='i')
> In [26]: b=scicore.arange(10,dtype='l')
> In [27]: a.dtypedescr == b.dtypedescr
> Out[27]: False  # !!
> With the attached patch (you should revise it, because I'm not used to
> write C extensions in the wild way), it works as it should:

Thanks for the patch.  I'll add a compare function for the 
typedescriptors.  There is already a C-API call for testing equivalence 
that we can use.

I'll probably use casting conventions to decide on greater or less than 
if they are not the same...

> However, I cannot see the way to make the a.dtype == b.dtype
> comparison to work well. I'm trying to figure out where the heck
> should I implement the tp_compare function for this case, but I can't.
> Some clues anyone? Well, perhaps this is not very important, but I
> have been bitten enough by the 'i' vs 'l' dichotomy and I'd love that
> scipy_core finally does the correct thing.

We would have to create a meta-class and re-define the comparison 
function.  This would also let us change how these type objects print. 
The a.dtype is a typeobject which means that it's an *instance* of the 
PyType_Type.  We would create our own PyScalarType_Type, inherit from 
PyType_Type and then use this has the base-type of all the array scalars 
(instead of object).

So, I'm not surprised you didn't know where to add the compare.  I 
barely learned myself during the course of this work.


> BTW, it seems that support for scipy_core homogeneous arrays (both
> numerical and strings) in PyTables is in place. Now, it remains
> records and unicode strings. I'll keep you informed on my progress. 

Fantastic.  If you could help us develop a numcompat module that would 
be great...

More information about the Scipy-dev mailing list