<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">As of 1.5.1 this worked: <div><br></div><div>>>> numpy.__version__</div><div>1.5.1</div><div>>>> numpy.uint64(5) & 3</div><div>1L</div><div><br></div><div><br></div><div>So, this is a regression and a bug. It should be fixed so that it doesn't raise an error. I believe the scalars were special cased so that a raw 3 would not be interpreted as a signed int when it is clearly unsigned. The casting rules were well established over a long period. They had issues, but they should not have been changed like this in a 1.X release. </div><div><br></div><div>Fortunately there are work-arounds and these issues arise only in corner cases, but we should strive to do better. </div><div><br></div><div>-Travis</div><div> </div><div><br></div><div><br><div><div>On Apr 6, 2012, at 12:45 AM, Charles R Harris wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, Apr 5, 2012 at 11:39 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</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 class="im">On Thu, Apr 5, 2012 at 11:16 PM, Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Which version of NumPy are you using. This could be an artefact of the new casting rules. <div><br></div><div>This used to work. So, yes, this is definitely a bug. </div><div><br>
</div>
</div></blockquote></div><div><br>It's because the '3' is treated as signed, so the uint64 needs to be cast to something of higher precision, of which there is none. You can either use uint64(3) or just stick to int64. I don't know if this used to work or not, mixing signed and unsigned has always led to higher precision in arithmetic operations, even (mistakenly in my opinion) promoting uint64(5) + 3 to lower precision float64.<br>
<br></div></div></blockquote><div><br>In particular, in this case it is because two scalars are used. It works fine for arrays<br><br>In [11]: ones(3, uint64) & 3<br>Out[11]: array([1, 1, 1], dtype=uint64)<br><br>Chuck <br>
</div></div>
_______________________________________________<br>NumPy-Discussion mailing list<br><a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>http://mail.scipy.org/mailman/listinfo/numpy-discussion<br></blockquote></div><br></div></body></html>