12

Possible Duplicate:
why is 1>>32 == 1?

-1 as an int converted to binary is represented by 32 1's. When I right-shift it 31 times, I get 1 (31 0's and one 1). But when I right-shift it 32 times, I get -1 again. Shouldn't it be equal to 0?

Community
  • 1
  • 1
user183037
  • 2,549
  • 4
  • 31
  • 42
  • 1
    It looks like Java. I dont know of many languages that define the `>>>` operator. – leppie Jan 27 '11 at 07:55
  • I came across this while I was trying to learn the basics of Java, yes, but I didn't tag it so since I assumed bit shifting was a fairly generic concept. – user183037 Jan 27 '11 at 08:00
  • 1
    check: http://stackoverflow.com/questions/3170412/why-is-132-1 –  Jan 27 '11 at 08:01
  • In light of User's comment saying he's asking about shifting in general, and not specifically about Java, I think this is *not* an exact duplicate of the link given by @Bstn. That's also why I've added some language-agnostic information after my original answer (which is otherwise the same as the answers in the other question). – Rob Kennedy Jan 27 '11 at 08:14
  • This question is about a completely different operator. it is not a duplicate – Sam I am says Reinstate Monica Dec 27 '13 at 18:06

1 Answers1

18

The Java specification explains the shift operators as follows:

If the promoted type of the left-hand operand is int, only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (§15.22.1) with the mask value 0x1f. The shift distance actually used is therefore always in the range 0 to 31, inclusive.

The value of 32 & 0x1f is zero.

If the left operand is long, then you get an extra bit for the right operand, expanding the upper limit to 63 instead of 31.

In order to have any specific expected value from shifting -1 to the right, you need to specify the underlying binary representation of integers (e.g., two's complement) as well as the number of bits (e.g., 32). Each programming language can define those differently, but in the interest of keeping things simpler for the implementation, they'll usually specify that shifting by more than the number of available bits is not allowed. That's often because the underlying CPU hardware doesn't support it, either. After all, if you want to shift that many bits, the left operand no longer matters since the result will always be the same.

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
  • 1
    BTW it means you can get the top bit of `x` using `x >> 63` or `x >> -1` whether x is int or long. ;) – Peter Lawrey Jan 27 '11 at 08:48
  • Shifting may also depend on 32/64 bit system. – TheCottonSilk Jan 27 '11 at 09:19
  • @TheCottonSilk Not in Java; shifting works the same way, doesn't matter if you're using a 32-bit or 64-bit operating system or JVM. – Jesper Jan 27 '11 at 09:50
  • @Jesper: You are right. I did not notice the Java tag added during later edits :). My comment was general to compilers and underlying architecture to caution not to assume based on one scenario. – TheCottonSilk Jan 27 '11 at 09:59