2011/6/10 Benjamin Root <ben.r...@ou.edu> > > > On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root <ben.r...@ou.edu> wrote: >> >>> Came across an odd error while using numpy master. Note, my system is >>> 32-bits. >>> >>> >>> import numpy as np >>> >>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32 >>> False >>> >>> type(np.sum([1, 2, 3], dtype=np.int64)) == np.int64 >>> True >>> >>> type(np.sum([1, 2, 3], dtype=np.float32)) == np.float32 >>> True >>> >>> type(np.sum([1, 2, 3], dtype=np.float64)) == np.float64 >>> True >>> >>> So, only the summation performed with a np.int32 accumulator results in a >>> type that doesn't match the expected type. Now, for even more strangeness: >>> >>> >>> type(np.sum([1, 2, 3], dtype=np.int32)) >>> <type 'numpy.int32'> >>> >>> hex(id(type(np.sum([1, 2, 3], dtype=np.int32)))) >>> '0x9599a0' >>> >>> hex(id(np.int32)) >>> '0x959a80' >>> >>> So, the type from the sum() reports itself as a numpy int, but its memory >>> address is different from the memory address for np.int32. >>> >>> >> One of them is probably a long, print out the typecode, dtype.char. >> >> Chuck >> >> >> > Good intuition, but odd result... > > >>> import numpy as np > >>> a = np.sum([1, 2, 3], dtype=np.int32) > >>> b = np.int32(6) > >>> type(a) > <type 'numpy.int32'> > >>> type(b) > <type 'numpy.int32'> > >>> a.dtype.char > 'i' > >>> b.dtype.char > 'l' > > So, the standard np.int32 is getting listed as a long somehow? To further > investigate: > > >>> a.dtype.itemsize > 4 > >>> b.dtype.itemsize > 4 > > So, at least the sizes are right. > > Ben Root >
long on a 32 bit computer is indeed int32. I think your issue is that in your version of numpy, numpy.dtype('i') != numpy.dtype('l') (while they are equal e.g. in Numpy 1.5.1). -=- Olivier
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion