Win a copy of Learn Spring Security (video course) this week in the Spring forum!

# Right shift

Poornachandran R
Ranch Hand
Posts: 47
System.out.println(3 >> 32);
prints 3.
Can anyone tell me how ?
Poorna

Shishio San
Ranch Hand
Posts: 223
y>>x is similar to y>>x%32 if y is in and y>>x%64 if y is long, where x is the number of bits you want to shift with. in your exemple 3>>32 is computed as 3>>32%32 thus 3>>0 and therefore the result is 3.

Alfred Kemety
Ranch Hand
Posts: 279
Shishio way is right putting in mind that the right operand is + integer ( x >= 0 )
If it's negative you should apply JLS way:

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.
If the promoted type of the left-hand operand is long, then only the six 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 0x3f. The shift distance actually used is therefore always in the range 0 to 63, inclusive.

Thanks Shishio for the typo
[ October 29, 2002: Message edited by: Alfred Kemety ]

Shishio San
Ranch Hand
Posts: 223

Poornachandran R
Ranch Hand
Posts: 47
Hai Shishio San,
You have told that if x >> y means, x >> y%32, but why is like that ?

Shishio San
Ranch Hand
Posts: 223
y represents the shift distance and it can't be greater than what the variable type (32 for int or 64 for long) can hold

Barkat Mardhani
Ranch Hand
Posts: 787
posted by Poorna:

Hai Shishio San,
You have told that if x >> y means, x >> y%32, but why is like that ?

That is how compiler will treat right shift.
Also, a while ago someone posted a request that if there is an easier way to solve these shifting questions without actually finding the binary equavalent and shifting and finding decimal equivalent. I put together an alternative. I found it accurate. What do you guys think:
Shift Operators
A op B
Assuming A is any integral value except long. For long A, replace 32 with 64:
1. B = B%32
2. If B is negative and not –32 : B=B+32
3. For signed right shift operator (>> , divide A successively by 2, B number of times. Round down the final result if A is positive. Round up the final result if A is negative.
4. For signed left shift operator (<< ; multiply A succesively by 2, B number of times. If (32-B)th bit of original A value is 1, make the result –ve if it is not already negative. If the final result is more than Integer.MAX_VALUE, make final result 0.
5. For unsigned right shift operator (>>> with postive A, same rules as number 3 above.
6. For unsigned right shift operator (>>> with negative A, do it conventional way:
a. find the 2’s compliment of negative A
b. right shift by B bits, inserting 0 on the left
c. find the decimal of above.
Examples:
int A = 200, B = 2
A >> B;
1. B=B%32 => B=2
2. B=2
3. result=50
Try more for yourself. Let me know if you have any questions.
Thanks
Barkat

Jim Crawford
Greenhorn
Posts: 14
Originally posted by Shishio San:
y>>x is similar to y>>x%32 if y is in and y>>x%64 if y is long, where x is the number of bits you want to shift with. in your exemple 3>>32 is computed as 3>>32%32 thus 3>>0 and therefore the result is 3.

The remainder operator is quite confusing on this topic. It did seem like an odd rule, but is deducted from the JLS rule. I'd recommend using the normal JLS rule.

Shishio San
Ranch Hand
Posts: 223

The remainder operator is quite confusing on this topic. It did seem like an odd rule, but is deducted from the JLS rule. I'd recommend using the normal JLS rule.

JLS states the same thing only expressed differently.

Todd Killingsworth
Greenhorn
Posts: 28
Hi Poornachandran -
A lot of detailed discussion is going on about <HOW> right shift operator behaves, but no one has answered your question, "Why?".
The best answer I've heard is described in Heller & Robert's book - Complete Java 2 Certification, although it's somewhat shrouded in myth. Apparently some company designed a CPU with very large registers for the time, for some type of real-time control system. As part of its design, any number of bits could be shifted for any of its registers. It was also set up so that any single instruction in the CPU couldn't be interrupted.
The problem in this - A developer could accidentally or maliciously write code that would shift a massive number ,effectively hijacking the CPU for minutes at a time. Not a good feature for a control system
The next version of the CPU introduced limiting the shift to the size of the target register.
HTH,
Todd