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

[Mark Wiebe]

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.

-Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110316/f91fa9f4/attachment.html>