[Numpy-discussion] hashing dtypes, new variation, old theme

[Robert Kern]

On Wed, Mar 16, 2011 at 12:15, Mark Wiebe <mwwiebe at gmail.com> wrote:
> On Wed, Mar 16, 2011 at 10:00 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Wed, Mar 16, 2011 at 11:55, Robert Kern <robert.kern at gmail.com> wrote:
>> > On Wed, Mar 16, 2011 at 11:43, Matthew Brett <matthew.brett at gmail.com>
>> > wrote:
>> >
>> >> I can git-bisect it later in the day, will do so unless it's become
>> >> clear in the meantime.
>> >
>> > I'm almost done bisecting.
>>
>> 6c6dc487ca15818d1f4cc764debb15d73a61c03b is the first bad commit
>> commit 6c6dc487ca15818d1f4cc764debb15d73a61c03b
>> Author: Mark Wiebe <mwwiebe at gmail.com>
>> Date:   Thu Jan 20 20:41:03 2011 -0800
>>
>>    ENH: ufunc: Made the iterator ufunc default
>>
>> :040000 040000 15033eb0c0e295161cd29a31677e7b88ac431143
>> ae077a44ccce0014e017537b31f53261495f870e M      numpy
>
> I'm guessing this is another case where the type numbers being ambiguous is
> the problem. On my 64-bit system:
>  >>> np.dtype(np.int) == np.dtype(np.long)
> True
>>>> hash(np.dtype(np.int)) == hash(np.dtype(np.long))
> False
>>>> np.dtype(np.int).num
> 7
>>>> np.dtype(np.long).num
> 9
> On a 32-bit system, types 5 and 7 are similarly aliased. By modifying the
> example slightly, possibly just switching the "data0 - 10" to "10 + data0",
> 1.5 probably will fail this test as well.

Correct.

Should we even include the type_num in the key to be hashed for the
builtin dtypes? They are not used in the tp_richcompare comparison,
only the kind and el_size.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco