This week's book giveaway is in the Jobs Discussion forum. We're giving away four copies of Customer Requirements for Developers and have Marcho Behler on-line! See this thread for details.

Hi all, I need some better explanation hon shift operators like >> << and >>> on isgned and unsigned numbers. If it is in low level i am very happy. ie. like when shift operator applies on a number how the compiler will convert that number and give it to the output?? like is it use 2's complement method or one complement method ??? please give some detailed explanaation so that i can work out on shift operators. Thank you for java ranch for providing this chance.

Ram, Did u check out the posts ....? Well there is one out there posted today or yesterday And Suresh Selvaraj has given a very nice & clear explanation.... Thanks to Suresh... Ram do check it out Aruna

Aru Ven
Ranch Hand

Joined: Sep 28, 2000
Posts: 199

posted

0

The subject of the post is Shift Operators & the Author is Mark Szymanowski HTH Aruna

Ram Chalasani
Greenhorn

Joined: Nov 20, 2000
Posts: 2

posted

0

Originally posted by Aru Ven: The subject of the post is Shift Operators & the Author is Mark Szymanowski HTH Aruna

Thank you aruna Actually i have seen the posting but that is in high level. I need in low level clarification. I have seen some explanation in Marcus green site? In that i didn't understand why when we are shifiting with 32 it is doing mod 32 operation and then doing shift. eg: 10 >> 32 results 10 only. in that site he explained that below 31 it will do normal shifting but whenever you will get more than 31 it will do mod32 operation and it will shift with the resultant. like 10 >> 33 first mod operation carries i.e 33%32 = 1 then shift operation 10>>1 i.e 5 I need to know why this mod 32 is coming into picture. Once again thak you aruna bye Ram

Hi, Here are the points to remember. 1.Any variable of type int occupies 4 bytes which is 4*8 bits i.e 32 bits. Bit pattern of an Integer: Example: 0000 1111 0000 1111 0000 1111 0000 1111 ==> 32 bits Now,when you need to perform bit shift operation ( be it << or >> shift ), you are left with only 31 bits i.e you have only 31 positions available for shift operation. This is the reason why you cannot shift more than 31 bits on an integer variable. So, whenever the number of bits to be shifted is more than 31 say 32, you need to shift (Number of bits to be shifted)%32 which in our case is 32%32 i.e zero. Example: Unsigned right shift operation on an int variable x. 1. int x=-4; x>>>32; Since the number of bits to be shifted is more than 31, you need to shift 32%32 which is zero. So the above shift is equivalent to, int x = -4; x>>>0; Since no right shift operation is performed, the result is same as the original number i.e. -4. FYI: The statement, "Unsigned right shift operation on a Negative integer always returns a Positive integer" - is FALSE. - Suresh Selvaraj

Suresh Selvaraj, (author of JQuiz)<br />SCJP2<br /><a href="http://www.decontconsulting.com" target="_blank" rel="nofollow">www.decontconsulting.com</a>

Ram, An integer type is represented as a 32 bit number. So an int type with value 10 is represented as 0000 0000 0000 0000 0000 0000 0000 1010 shifting n bits right means moving each bit n number of times to the right. So if you shift this number by 2 ( >>2) positions to the right the last two bits fall off and they are discarded and the new bits that are added take the value of the most significant bit ie the last one on the left side. so the number becomes 0000 0000 0000 0000 0000 0000 0000 0010 which is decimal value 2. Now if you ask the processor to do shift the same number right by 1024 bits (10 >>1024). After you have moved the bits by 31 positions it becomes futile to carry out further shifting operations. The value will remain constant and the only thing you manage to do is waste processor cycles. Shifting by huge numbers can effectively cripple the cpu eg : 2 >>3282732723897. Therefor it was decided to limit the number of shift operations to a level where the result is significant in some way. The best way to do this is apply a modulus of the total number of bits to the shift operator so 10 >>1024 will not change any thing because 1024 mod 32 is 0. The general rule for shift operations is what comes in from the right side is always 0 and what comes in from the left is always the value of the most significant bit except in the case of the unsigned right shift (>>>) where the new bit is set to zero. What falls off on the other side is always discarded.

Hi, This is my first entry into Java Ranch. I read Mr. Suresh replay to the above subject. At the end he had given an information that the result of unsigned right sift on an -ve integer is always positive is FALSE. But in Mr. Sahir's reply it is mentioned as unsigned right shift will always introduce 0 in the MSB. When 0 is inserted it should be positive. Pl. clarify as how the information given by Mr. Suresh be False Tanx.

bill bozeman
Ranch Hand

Joined: Jun 30, 2000
Posts: 1070

posted

0

Srinivasan, thanks for joining the ranch. There are a couple of instances where it won't be false. The first one is when you try to do an unsigned right shift with a number that is 0 or the modulo gives you 0. Better explained with an example.

The other time you can get a negative number is when you do shifts with bytes. The point to remember here is that it will be converted to an int before the shift takes place.

In this case, you add 0's to the highest bits, but then you chop them off when you cast it back to a byte. So you still end up with a negative number. Bill

Sahir Shah
Ranch Hand

Joined: Nov 05, 2000
Posts: 158

posted

0

The value will always be positive if a shift actually takes place. In an unsigned right shift operator (v>>>n) if the value of n is greater than the number of bits in v , and n is an integral multiple of v then no shifting takes place eg : int i = -1; i = i >>>64; integer values are 32 bits long. so 64/32 = 2 2 is an integer value . Hence the number of places to shift by is 0. ie no shifting takes place. i will still contain -1. I hope its clear now.