On Wed, Mar 16, 2011 at 10:00 AM, Robert Kern <robert.k...@gmail.com> wrote:
> On Wed, Mar 16, 2011 at 11:55, Robert Kern <robert.k...@gmail.com> wrote: > > On Wed, Mar 16, 2011 at 11:43, Matthew Brett <matthew.br...@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 <mwwi...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
