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

Gary Peck

Greenhorn

Posts: 15

posted 12 years ago

- 0

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

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

posted 12 years ago

- 0

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 ]

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

posted 12 years ago

- 0

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?

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

posted 12 years ago

- 0

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).

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).

*Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.* - Ernst F. Schumacher

Gary Peck

Greenhorn

Posts: 15

posted 12 years ago

- 0

Thank you for speaking my PE language!

However...you've gone and confused me again!! haha

You said:

but isn't 11111111 actually a

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

posted 12 years ago

- 0

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).

So the range for bytes in 2's complement form is -128 (0x80) to 127 (0x7f).

*Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.* - Ernst F. Schumacher

Phil Chuang

Ranch Hand

Posts: 251

posted 12 years ago

- 0

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.

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.

I agree. Here's the link: http://aspose.com/file-tools |