Hi Thomas, I asked on the numpy list regarding our dtype hashability issues, and it seems PyCUDA's usage of dtypes is perfectly legitimate, as indicated by Robert Kern's reply which I've forwarded below. To put us in a position where we can file this as a bug with the numpy guys, would you be able to boil your example down to a simple test script (that, ideally, only uses numpy)?
Andreas
--- Begin Message ---On Tue, Dec 27, 2011 at 01:22, Andreas Kloeckner <li...@informa.tiker.net> wrote: > Hi all, > > Two questions: > > - Are dtypes supposed to be comparable (i.e. implement '==', '!=')? Yes. > - Are dtypes supposed to be hashable? Yes, with caveats. Strictly speaking, we violate the condition that objects that equal each other should hash equal since we define == to be rather free. Namely, np.dtype(x) == x for all objects x that can be converted to a dtype. np.dtype(float) == np.dtype('float') np.dtype(float) == float np.dtype(float) == 'float' Since hash(float) != hash('float') we cannot implement np.dtype.__hash__() to follow the stricture that objects that compare equal should hash equal. However, if you restrict the domain of objects to just dtypes (i.e. only consider dicts that use only actual dtype objects as keys instead of arbitrary mixtures of objects), then the stricture is obeyed. This is a useful domain that is used internally in numpy. Is this the problem that you found?
--- End Message ---
_______________________________________________ PyCUDA mailing list PyCUDA@tiker.net http://lists.tiker.net/listinfo/pycuda
