[Numpy-discussion] hashing dtypes, new variation, old theme
Mark Wiebe
mwwiebe@gmail....
Wed Mar 16 12:15:36 CDT 2011
On Wed, Mar 16, 2011 at 10:00 AM, Robert Kern <robert.kern@gmail.com> wrote:
> On Wed, Mar 16, 2011 at 11:55, Robert Kern <robert.kern@gmail.com> wrote:
> > On Wed, Mar 16, 2011 at 11:43, Matthew Brett <matthew.brett@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@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.scipy.org/pipermail/numpy-discussion/attachments/20110316/f91fa9f4/attachment.html
More information about the NumPy-Discussion
mailing list