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.

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

Joined: Jun 03, 2003
Posts: 15

posted

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?

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

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

Joined: Jun 03, 2003
Posts: 15

posted

0

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

Joined: Jan 30, 2002
Posts: 3451

posted

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

Phil Chuang
Ranch Hand

Joined: Feb 15, 2003
Posts: 251

posted

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.

I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com