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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
