[Numpy-discussion] hashing dtypes, new variation, old theme
Wed Mar 16 15:21:50 CDT 2011
On Wed, Mar 16, 2011 at 10:53 AM, Robert Kern <email@example.com> wrote:
> On Wed, Mar 16, 2011 at 12:15, Mark Wiebe <firstname.lastname@example.org> wrote:
> > On Wed, Mar 16, 2011 at 10:00 AM, Robert Kern <email@example.com>
> >> On Wed, Mar 16, 2011 at 11:55, Robert Kern <firstname.lastname@example.org>
> >> > On Wed, Mar 16, 2011 at 11:43, Matthew Brett <email@example.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 <firstname.lastname@example.org>
> >> 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
> > 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 +
> > 1.5 probably will fail this test as well.
> 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.
That sounds like a good fix to me. Whenever objects compare equal, they
should hash to the same value.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion