# [Numpy-discussion] numpy type mismatch

Charles R Harris charlesr.harris@gmail....
Fri Jun 10 15:24:57 CDT 2011

```On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root <ben.root@ou.edu> wrote:

>
>
> On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris <
> charlesr.harris@gmail.com> wrote:
>
>>
>>
>> On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root <ben.root@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
>>>
>>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20110610/e14d52ba/attachment-0001.html
```