On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root <ben.r...@ou.edu> wrote:
> > > 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: > > Yes, long shifts around from int32 to int64 depending on the OS. For instance, in 64 bit Windows it's 32 bits while in 64 bit Linux it's 64 bits. On 32 bit systems it is 32 bits. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
