<div class="gmail_quote">On Fri, Jun 10, 2011 at 9:55 PM, Benjamin Root <span dir="ltr">&lt;<a href="mailto:ben.root@ou.edu">ben.root@ou.edu</a>&gt;</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 class="im">On Fri, Jun 10, 2011 at 8:51 PM, Keith Goodman <span dir="ltr">&lt;<a href="mailto:kwgoodman@gmail.com" target="_blank">kwgoodman@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris<br>
<div>&lt;<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>&gt; wrote:<br>
</div><div>&gt; On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau &lt;<a href="mailto:shish@keba.be" target="_blank">shish@keba.be</a>&gt; wrote:<br>
<br>
</div><div>&gt;&gt; But isn&#39;t it a bug if numpy.dtype(&#39;i&#39;) != numpy.dtype(&#39;l&#39;) on a 32 bit<br>
&gt;&gt; computer where both are int32?<br>
&gt;&gt;<br>
&gt;<br>
&gt; Maybe yes, maybe no ;) They have different descriptors, so from numpy&#39;s<br>
&gt; perspective they are different, but at the hardware/precision level they are<br>
&gt; the same. It&#39;s more of a decision as to what  != means in this case. Since<br>
&gt; numpy started as Numeric with only the c types the current behavior is<br>
&gt; consistent, but that doesn&#39;t mean it shouldn&#39;t change at some point.<br>
<br>
</div>Maybe this is the same question, but are you maybe yes, maybe no on this too:<br>
<div><br>
    &gt;&gt;&gt; type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32<br>
    False<br>
<br>
</div>Ben, what happens if you put an axis in there? Like<br>
<br>
    &gt;&gt;&gt; np.sum([[1, 2, 3], [4,5,6]], axis=0).dtype == np.int32<br></blockquote></div><div><br>The same thing happens as before.<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">



<br>
Just wondering if this is another different-dtype-for-different-axis case.<br></blockquote></div><div><br>No, I think Chuck has it right and that this is the result of the recent cleanup work for ufunc casting rules.  However, I am so entirely unfamiliar with ufuncs that I really don&#39;t know how to investigate this.  Can we get Mark Wiebe&#39;s opinion on this?  I suspect he might recognize the problem right away.<br>
</div></div></blockquote><div><br></div><div>Yeah, it&#39;s basically a misfeature of NumPy which is apparently inherited from Numeric. The type resolution changes to 1.6 changed where this would pop up, but it&#39;s always been there in the code. I suspect that eliminating the long type, and making it an alias to either int or longlong depending on the platform, would fix all of this on all current platforms.</div>
<div><br></div><div>Cheers,</div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>

<br>Ben Root<br><br></div></div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br>