Poornachandran R

Ranch Hand

Posts: 47

Shishio San

Ranch Hand

Posts: 223

posted 14 years ago

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

Posts: 279

posted 14 years ago

Shishio way is right putting in mind that the right operand is + integer ( x >= 0 )

If it's negative you should apply JLS way:

Thanks Shishio for the typo

[ October 29, 2002: Message edited by: Alfred Kemety ]

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

Posts: 223

Poornachandran R

Ranch Hand

Posts: 47

Shishio San

Ranch Hand

Posts: 223

Barkat Mardhani

Ranch Hand

Posts: 787

posted 14 years ago

posted by Poorna:

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

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

posted 14 years ago

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.

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

posted 14 years ago

JLS states the same thing only expressed differently.

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.

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

Todd Killingsworth

Greenhorn

Posts: 28

posted 14 years ago

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

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