aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes shifting Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "shifting" Watch "shifting" New topic
Author

shifting

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
This is in regards to the appliedreasoning mock exam
Question 23: what's the value of (byte)0X81 >> 2
a) 0x20
b) 0x3fffffe0
c) 0xe0
d) 0xffffffe0
THe answer given is d, but I thought c. The number 0x81 would be converted to an int, then shifted, and is cast back down to a byte- or so I thought. What's going on here?
Another one related to that is question 25: give the result of 0x1 << 36
The answer says it uses 36 mod 31 to get 0x1 << 5, I thought it was modulo 32? Anyway I'm not sure how to test this, when I try and run something like this, I get an error saying "left shift exceeds size of the type being shifted"
Please help!
Thanks!
Manju Swamy
Greenhorn

Joined: Mar 03, 2000
Posts: 14
Here are the quotes from JLS:


An integer literal may be expressed in decimal (base 10), hexadecimal (base 16), or octal (base 8):
An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (�4.2.1).


int i = 0x81;
The value of Ox81 in decimal system is 129.
The binary representation is 0000 0000 0000 0000 0000 0000 1000 0001
byte b = (byte) i;
When the value is casted to byte the last 8 bits are stored in the variable b.
The binary representation is 1000 0001 (the most significant bit is the sign bit).
Now value of b in decimal system is -127.
System.out.println("value of b >> 2 in Decimal: " + b >> 2);

Following are the quote from Mughal and Rasmussen book:
Since char, byte and short operands are promoted to either int or long, the result of applying these bitwise operators is always either an int or a long value.


Additional reading on Shift Operators from JLS.
Now the byte b variable is promoted to int.
The binary representation is 1111 1111 1111 1111 1111 1111 1000 0001
The decimal value is still -127.
The Hex representation is ffffff81
After the shit operation >> (shift right with sigh bit) the return value is int in this case.
The binary representation is 1111 1111 1111 1111 1111 1111 1110 0000
The decimal value is -32.
The Hex representation is ffffffe0
Hence the answer.


Another one related to that is question 25: give the result of 0x1 << 36<br /> The answer says it uses 36 mod 31 to get 0x1 << 5, I thought it was modulo 32? Anyway I am not sure how to test this, when I try and run something like this, I get an error saying "left shift exceeds size of the type being shifted"<br />
<br />
<br /> You are right on this one. You can verify by running the following code and reading the above mention JLS on Shift Operators.<br /> Note: Moderators this can be moved Mock Exam Errata.<br />
[This message has been edited by Manju Swamy (edited April 26, 2000).]


Mind is like a parachute. It works only when it is open.
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Thank you, that helps clear some things up. The (byte) cast was bringing 0x81 down to byte, but the shift promoted it back to integer, thus giving the answer as a hexadecimal int.
I still got the "left shift exceeds size of the type being shifted" error on the following line:
System.out.println("Result of 0x1 << 36 is: " + Integer.toHexString(0x1 << 36));

However, I do understand how to get the answer on that one. Thank you.
Manju Swamy
Greenhorn

Joined: Mar 03, 2000
Posts: 14
Here is the code out put:

I am using winnt java from SUN version 1.2.2.
Here is how you can find the java version.
C:\>java -version
java version "1.2.2"
Classic VM (build JDK-1.2.2-001, native threads, symcjit)
What platform / java version are you using?
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
My java version says:
Java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)
I'm running on Windows NT 4.0
Suma Narayan
Ranch Hand

Joined: Apr 03, 2000
Posts: 136
Hi,
The above example worked for me. My java version is
java version "1.2.1"
Classic VM (build JDK-1.2.1-A, native threads)
and I have Windows 95.
maha anna
Ranch Hand

Joined: Jan 31, 2000
Posts: 1467
Brain,
0x1 << 36 is equivalent to
0x1 << 0x ff ff ff 00100100 ( I am using spaces and 0's and 1's just to make it visually clear )
Since the decimal literal 36 defaults to primitive type 'int'
LHS operand shiftoperator RHS operand
According to JLS when you use shift operatiors (<<, >>, >>>), if the LHS operand is int then only the last 5 bits of RHS operand is used for shifting . SImillarly if the LHS operand is long then only the last 6 bits of RHS operand is used for shifting . Also note that shift operation can take place ONLY on int/long LHS operands. If anything < int type (byte/short/char) they are first promoted to int and then shifting takes place. LHS operand can't be float/double.
So in this case the val 1 is shifted left 4 places. (Since the last 5 bits (00100) constitutes value of 4. Also note that every time you left(right) shift by 1 place you in effect multiply (divide> the val by 2
So in my mind I just calculate the value 1 becomes
1 then 2 then 4 then 8 then 16 (after 4 shifts)
This is the correct result according to the JLS. In JDK 1.2.2 under WIN98 we get this result.
regds
maha anna
[This message has been edited by maha anna (edited April 27, 2000).]
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Thank you for the explanation. It is clear now what is going on
Brian
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944

Just some investigative work...for clarification...
The decimal value of 0x1 << 4 is 16, as explained.
In Manju's program, the use the of Integer.toHexString()
method prints 10. Which is to be read as 0x10. Maybe we
should change the last println statement to:
System.out.println("Result of 0x1 << 4 is: " + "0x" + Integer.toHexString(0x1 << 4));
For a couple of minutes, I was .
I am posting this just to clarify, in case
I have company in the confusion.
Regds.
- satya
maha anna
Ranch Hand

Joined: Jan 31, 2000
Posts: 1467
Thanks for sharing your experience Satya. I really appreciate your helpful nature. Yes appending "0x" helps in perceiving the result as HexValue.
regds
maha anna
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Hi,
could someone please explain this
if the LHS operand is int then only the last 5 bits of RHS operand is used for shifting . SImillarly if the LHS operand is long then only the last 6 bits of RHS operand is used for shifting especially the significance of 5 for int and 6 for long.
thanx
Rahul Mkar
[This message has been edited by rahul_mkar (edited June 05, 2000).]
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
rahul:
Say you are shifting my_int value by 34 (some num > 32)
then the actual shift is equal to shifting my_int with
2.
34 = 0010 0010
Now since we are shifting an int, only the low order 5
bits are used from the above num which will be 0 0010
ie; 2 (which is also 34-32 ).
However if you are shifting a my_long value by 34
the the lower order 6 bits are used. Meaning the variable
my_long is actually shifted by 34 bits 10 0010 and not
by 2 bits as with ints.
I thought every thing was clear above. Anyways, hope I am
able to show the difference. Also try and play with this code.
To make you think abt this I used 33 in the code....

Output is:
128 >> 33 = 64 128 shifted by 33 (0010 0001).
128 >> 1 = 64 128 shifted by 1 (0000 0001).
Shifting 128L now ......
128L >> 33 = 0 128L shifted by 33 (0010 0001).
128L >> 1 = 64 128L shifted by 1 (0000 0001).
Hope this helps, else take a break and read from the
beginning of the whole thread.
Regds.
- satya
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: shifting
 
Similar Threads
>> shift question
Shifting - hex digits
About primitive promotion.
Practice exam question
Shift Operator