On Wed, Mar 16, 2011 at 10:53 AM, Robert Kern <[email protected]> wrote:
> On Wed, Mar 16, 2011 at 12:15, Mark Wiebe <[email protected]> wrote: > > On Wed, Mar 16, 2011 at 10:00 AM, Robert Kern <[email protected]> > wrote: > >> > >> On Wed, Mar 16, 2011 at 11:55, Robert Kern <[email protected]> > wrote: > >> > On Wed, Mar 16, 2011 at 11:43, Matthew Brett <[email protected] > > > >> > 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 <[email protected]> > >> 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. That sounds like a good fix to me. Whenever objects compare equal, they should hash to the same value. -Mark
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
