File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Right shift Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Right shift" Watch "Right shift" New topic
Author

Right shift

Poornachandran R
Ranch Hand

Joined: Sep 11, 2002
Posts: 47
System.out.println(3 >> 32);
prints 3.
Can anyone tell me how ?
Poorna
Shishio San
Ranch Hand

Joined: Aug 29, 2002
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.


Whatever doesn't kill us ...<br />Is probably circling back for another try.<br />SCJP 1.4
Alfred Kemety
Ranch Hand

Joined: Aug 14, 2002
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 ]

Alfred Raouf - Egypt - SCJP 1.4<br />Kemety.equals(Egyptian) // returns true
Shishio San
Ranch Hand

Joined: Aug 29, 2002
Posts: 223
Alfred there's a typo in your answer: (x>=0) not y
Poornachandran R
Ranch Hand

Joined: Sep 11, 2002
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

Joined: Aug 29, 2002
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

Joined: Aug 05, 2002
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

Joined: Jan 31, 2002
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

Joined: Aug 29, 2002
Posts: 223
Originally posted by Jade McCormack:

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

Joined: Jan 30, 2002
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Right shift