[SciPy-user] Is numpy's argsort lying about its numpy.int32 types?

[Ross Wilson]

Travis Oliphant <oliphant.travis <at> ieee.org> writes:

> 
> Rob Clewley wrote:
> > Fair enough, but it does cause a *real* problem when I extract the
> > values from aa and pass them on to other functions which try to
> > compare their types to the integer types int and int32 that I can
> > import from numpy. Since the values I'm testing could equally have
> > been generated by functions that return the regular int type I can't
> > guarantee that those values will have a dtype attribute!
> >   
> You don't have to use the bit-width names (which can be confusing) in 
> such cases.   There is a regular name for every C-like type
> 
> You can use the names  byte, short, intc, int_, longlong (and 
> corresponding unsigned names prefixed with u)
> 
> > I have some initialization code for a big class that has to set up
> > some state differently depending on the type of the input. So, I was
> > trying to do something like this
> >
> > if type(x) in [int, int32]:
> >     ## do stuff specific to integer x
> >   
> > but now it seems like I'll need
> >
> > try:
> >     isint = x.dtype == dtype('int32')
> > except AttributeError:
> >     isint = type(x) == int
> > if isint:
> >     ## do stuff specific to integer x
> >   
> 
> try:
> 
> if isinstance(x, (int, integer))
> 
> integer is the super-class of all c-like integer types.
> 
> > -- which is a mess! Is there a better way to do this test cleanly and
> > robustly? And why couldn't c_long always correspond to a unique numpy
> > name (i.e., not shared with int32) regardless of how it's implemented?
> >   
> There is a unique numpy name for all of them.  The bit-width names just 
> can't be unique.
> 
> > Either way it would be helpful to have a name for this "other" int32
> > that I can test against using the all-purpose type() ... so that I
> > could test something like
> >
> > type(x) in [int, int32_c_long, int32_c_int]
> >   
> 
> isinstance(x, (int, intc, int_))
> 
> is what you want.
> 
> -Travis
> 

In a slightly different context, we have found a situation with the type
comparison of two *general* objects (ie, we don't know if they are numpy objects
or something else) that confused us mightily.

For example, in a recursive general object comparison function we have:
def compare(A, B):
    if type(A) is not type(B):
        return False
    <test for various types of object, split and compare components>

where the <...> code may call compare() recursively after splitting complex
objects into less complex objects.

The confusion comes when we debug a comparison that should return *equal* but
doesn't due to the type comparison saying the objects have different types. 
Printing the type() of A and B shows both as numpy.int32 but they are *not*
equal types (the id(type()) values differ).

That is confusing.  Wouldn't it be better if numpy types that have the same
underlying bit representation (integer, 32bit) use the same type object.  Or if
that can't be done, arrange for the different object types to display different
representation strings?

That would remove the confusion we experience when we see the same type string
for objects that aren't the same type.

Ross