[Numpy-discussion] Bitwise operations and unsigned types

[Travis Oliphant]

As of 1.5.1 this worked: 

>>> numpy.__version__
1.5.1
>>> numpy.uint64(5) & 3
1L


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.  

Fortunately there are work-arounds and these issues arise only in corner cases, but we should strive to do better.  

-Travis
    


On Apr 6, 2012, at 12:45 AM, Charles R Harris wrote:

> 
> 
> On Thu, Apr 5, 2012 at 11:39 PM, Charles R Harris <charlesr.harris at gmail.com> wrote:
> 
> 
> On Thu, Apr 5, 2012 at 11:16 PM, Travis Oliphant <travis at continuum.io> wrote:
> Which version of NumPy are you using.  This could be an artefact of the new casting rules.     
> 
> This used to work.   So, yes, this is definitely a bug. 
> 
> 
> 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.
> 
> 
> In particular, in this case it is because two scalars are used. It works fine for arrays
> 
> In [11]: ones(3, uint64) & 3
> Out[11]: array([1, 1, 1], dtype=uint64)
> 
> Chuck 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120406/0f70d165/attachment.html>