[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 : a=scicore.arange(10,dtype='i')
> In : b=scicore.arange(10,dtype='l')
> In : a.dtypedescr == b.dtypedescr
> Out: 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
More information about the Scipy-dev