[Numpy-discussion] numpy type mismatch

[Charles R Harris]

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

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