• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

shift operators and hex...HELP!!!!!

 
Gary Peck
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could someone explain (in P.E. major language ) why the answer is f? I included the explanation, but it doesn't really make a lot of sense!

What is the result of attempting to compile and run the program?
a. Prints: ffffffff,ffffffff,ffffffff
b. Prints: ffffffff,ffffffff,7fffffff
c. Prints: ffffffff,7fffffff,ffffffff
d. Prints: ffffffff,7ffffffe,7ffffffe
e. Prints: fffffffe,ffffffff,ffffffff
f. Prints: fffffffe,ffffffff,7fffffff
g. Prints: fffffffe,7fffffff,ffffffff
h. Prints: fffffffe,7fffffff,7fffffff
i. Run-time error
j. Compile-time error
k. None of the above

If the left-hand operand of a shift operator, <<, >> and >>>, is of type int, then the shift distance is always within the range of 0 to 31, inclusive; and is specified by the least significant 5 bits of the right hand operand. Similarly, if the left-hand operand of a shift operator is of type long, then the shift distance is always within the range of 0 to 63, inclusive; and is specified by the least significant 6 bits of the right hand operand. The left shift operator, <<, shifts each bit of the left operand to the left a distance specified by the shift distance. A number of bits that is equal to the shift distance are shifted out of the left-most bit position and are lost. A number of bits that is equal to the shift distance are shifted in at the right. The signed right shift operator, >>, shifts each bit of the left operand to the right a distance specified by the shift distance. A number of bits that is equal to the shift distance are shifted out of the right-most bit position and are lost. A number of bits that is equal to the shift distance are shifted in at the left. The value of each bit that is shifted in at the left is equal to the value of the sign bit. The signed right shift operator maintains the sign of the left operand. The unsigned right shift operator, >>>, is similar to the signed right shift operator except for the fact that each bit shifted in at the left is zero.
 
Phil Chuang
Ranch Hand
Posts: 251
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you shift left "<<", all the bits are moved over one to the left and a zero is moved in at the rightmost position. If this was an 8 bit number, it'd go from 11111111 to 11111110. This is why the right most hex digit turns from an "F" to an "E", because it went from a value of 15 to 14. Since all the other bits are 1 anyway, the rest of the number is unaffected.
When you shift right ">>", all the bits are moved over one to the right, and a ZERO OR ONE is moved in DEPENDING ON THE BIT THAT WAS JUST THERE. This is usually the "sign bit" which determines whether or not the number is negative or positive. So, the same value bit is shifted in so that the sign of the number is preserved.
When you shift right without preserving the sign bit ">>>", it behaves exactly how you'd expect it to behave - by shifting a zero in. That's why the left most digit goes from "F" (1111) to "7" (0111).
EDIT: darn smilies.
[ December 19, 2003: Message edited by: Phil Chuang ]
 
Gary Peck
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does the 0xffffffff represent just a huge number that must be converted to binary before the shift?
So...each digit can be 0-9 a-f so that each shift of a digit changes the number by the power of 16?
It just seems so difficult to try and figure out what the number in hex converts to in binary to do the shift.
Am I totally making this harder than it has to be?
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hex is just a more convenient way of expressing a binary integer. Each hex digit represents 4 bits so you save yourself 4 times the "paper" in representing the value. Here are the individual representations:
  • 0000 - 0x0
  • 0001 - 0x1
  • 0010 - 0x2
  • 0011 - 0x3
  • 0100 - 0x4
  • 0101 - 0x5
  • 0110 - 0x6
  • 0111 - 0x7
  • 1000 - 0x8
  • 1001 - 0x9
  • 1010 - 0xa
  • 1011 - 0xb
  • 1100 - 0xc
  • 1101 - 0xd
  • 1110 - 0xe
  • 1111 - 0xf


  • So now if you see the hex value 0xff then you know that the binary representation is 11111111 or 255 (15 * 16 + 15 or 16^2 - 1).
     
    Gary Peck
    Greenhorn
    Posts: 15
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you for speaking my PE language!
    However...you've gone and confused me again!! haha
    You said:
    So now if you see the hex value 0xff then you know that the binary representation is 11111111 or 255 (15 * 16 + 15 or 16^2 - 1).

    but isn't 11111111 actually a negative number because of the 1 in the most significant position?
     
    Michael Morris
    Ranch Hand
    Posts: 3451
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You got me there Gary and you didn't. In pure binary 0xff is 255, but in 2's complement form, which is how Java stores bytes (8 bits), then its value would be -1. On the other hand if the value is an int (32 bits) then it is, as I said 255.
    So the range for bytes in 2's complement form is -128 (0x80) to 127 (0x7f).
     
    Phil Chuang
    Ranch Hand
    Posts: 251
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    To further clarify, there are two ways to view computer numbers:
    signed (-/+) or
    unsigned (+)
    For a byte (8 bits), the signed byte ranges from -128 to 127, and the unsigned byte from 0 to 255.
    I think that most java numeric types are signed, with the exception of chars, tho I may be wrong.
     
    Don't get me started about those stupid light bulbs.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic