<br><div class="gmail_quote">2011/6/10 Olivier Delalleau <span dir="ltr"><<a href="mailto:shish@keba.be">shish@keba.be</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">2011/6/10 Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau <span dir="ltr"><<a href="mailto:shish@keba.be" target="_blank">shish@keba.be</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><div></div><div>2011/6/10 Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root <span dir="ltr"><<a href="mailto:ben.root@ou.edu" target="_blank">ben.root@ou.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jun 10, 2011 at 3:24 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root <span dir="ltr"><<a href="mailto:ben.root@ou.edu" target="_blank">ben.root@ou.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br><br><div class="gmail_quote"><div><div></div><div>On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root <span dir="ltr"><<a href="mailto:ben.root@ou.edu" target="_blank">ben.root@ou.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Came across an odd error while using numpy master. Note, my system is 32-bits.<br><br>>>> import numpy as np<br>>>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32<br>False<br>>>> type(np.sum([1, 2, 3], dtype=np.int64)) == np.int64<br>
True<br>>>> type(np.sum([1, 2, 3], dtype=np.float32)) == np.float32<br>True<br>>>> type(np.sum([1, 2, 3], dtype=np.float64)) == np.float64<br>True<br><br>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:<br>
<br>>>> type(np.sum([1, 2, 3], dtype=np.int32))<br><type 'numpy.int32'><br>>>> hex(id(type(np.sum([1, 2, 3], dtype=np.int32))))<br>'0x9599a0'<br>>>> hex(id(np.int32))<br>'0x959a80'<br>
<br>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.<br><br></blockquote></div></div><div><br>One of them is probably a long, print out the typecode, dtype.char.<br>
<br>Chuck <br></div></div><br>
<br></blockquote></div></div><div><br>Good intuition, but odd result...<br><br>>>> import numpy as np<br>>>> a = np.sum([1, 2, 3], dtype=np.int32)<br>>>> b = np.int32(6)<br>>>> type(a)<br>
<type 'numpy.int32'><br>
>>> type(b)<br><type 'numpy.int32'><br>>>> a.dtype.char<br>'i'<br>>>> b.dtype.char<br>'l'<br><br>So, the standard np.int32 is getting listed as a long somehow? To further investigate:<br>
<br></div></div></blockquote></div></div><div><br>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.<br>
<br>Chuck<br></div><br></div></blockquote></div></div><div><br>Right, that makes sense. But, the question is why does sum() put out a result dtype that is not identical to the dtype that I requested, or even the dtype of the input array? Could this be an indication of a bug somewhere? Even if the bug is harmless (it was only noticed within the test suite of larry), is this unexpected?<br>
<br></div></div></blockquote></div></div><div><br>I expect sum is using a ufunc and it acts differently on account of the cleanup of the ufunc casting rules. And yes, a long *is* int32 on your machine. On mine<br><br>In [4]: dtype('q') # long long<br>
Out[4]: dtype('int64')<br><br>In [5]: dtype('l') # long<br>Out[5]: dtype('int64')<br><br>The mapping from C types to numpy width types isn't 1-1. Personally, I think we should drop long ;) But it used to be the standard Python type in the C API. Mark has also pointed out the problems/confusion this ambiguity causes and someday we should probably think it out and fix it. But I don't think it is the most pressing problem.<br>
<br>Chuck<br></div><br></div></blockquote></div></div><div><br>But isn't it a bug if numpy.dtype('i') != numpy.dtype('l') on a 32 bit computer where both are int32?<br><br></div></div></blockquote></div>
</div><div>
<br>Maybe yes, maybe no ;) They have different descriptors, so from numpy's perspective they are different, but at the hardware/precision level they are the same. It's more of a decision as to what != means in this case. Since numpy started as Numeric with only the c types the current behavior is consistent, but that doesn't mean it shouldn't change at some point.<br>
<br>Chuck<br></div></div></blockquote></div></div><div><br>Well apparently it was actually changed recently, since in Numpy 1.5.1 on a Windows 32 bit machine, they are considered equal with '=='.<br>Personally I think if the string representation of two dtypes is "int32", then they should be ==, otherwise it wouldn't make much sense given that you can directly test the equality of a dtype with a string like "int32" (like dtype('i') == "int32" and dtype('l') == "int32").<br>
</div></div></blockquote><div><br>I also just checked on a fresh install of numpy 1.6.0 on python 3.2, and both types are equal as well.<br>I've been playing quite a bit with numpy dtypes and it's the first time I hear two dtypes representing the exact same kind of data do not compare equal, so I'm still enclined to believe it should be considered a bug.<br>
<br>-=- Olivier<br></div></div><div style="visibility: hidden; left: -5000px; position: absolute; z-index: 9999; padding: 0px; margin-left: 0px; margin-top: 0px; overflow: hidden; word-wrap: break-word; color: black; font-size: 10px; text-align: left; line-height: 130%;" id="avg_ls_inline_popup">
</div>