# Hexadecimal two's Complement

I have this question, which I thought I knew how to do, however my method is wrong somewhere. I converted the numbers to binary, removed 1 then inverted them to get them in normal binary format. I then added 4 leading 0's to give me a 16 bit number then converted it back to two's complement in hex giving FEF7 Hex, which is the correct answer. However applying the same method to the second number gives F7FE, which is incorrect, as the answer should be 0F7E Hex according to the mark scheme. Can you please tell me where i'm going wrong?

Thanks

-
Either you or the mark scheme has a typo in what the answer should be. –  Samuel May 25 at 20:41

Ignacio showed the shortcut: sign-extension.

What you attempted is OK too, and it shows that you try to understand the process: convert to a 'plain value' then convert back to two's complement. But you must remember that this process is different for negative and positive numbers (and 0):

• for non-negative numbers (highest bit is 0) the value is simply the (positive or 0) value. No need to convert back or forth.

• for negative numbers (highest bit is 1 ) you can convert back to a positive number, add the extra 0's in front, and then convert back to negative.

You showed that you can do the second, now you only have to remember that this process makes no sense for a value that isn't negative to begin with!

-

You extend the MSb to the left, since that determines the sign. The value will not change at the new number of bits.

• 0xFEF7
• 0x07FE
-
...and, of course, you'll know the MSB is 1 if the leading hex digit is 8 or greater. If it is, you extend with F, else with 0. –  Ilmari Karonen May 26 at 5:29
@IlmariKaronen that applies only if the number has $4k$ digits, which may not be always true –  Vladimir Cravero May 26 at 7:19
@VladimirCravero: You mean $4k$ bits = $k$ hex digits. But yes, good point. No matter how perverse it might seem, somebody somewhere is bound to try representing, say, a 9-bit signed two's complement binary number as unsigned hex. At that point, you just have to know how many bits long the number is supposed to be, because you can't tell just by looking at the hex representation. –  Ilmari Karonen May 26 at 11:34
That's what I meant. And it is not that perverse. Imagine you have a 30bit signal somewhere in a data path, you want to set it to/test it against a particular value, using hex is easier and faster –  Vladimir Cravero May 26 at 11:38

You are wrong because you are using the same method for two situations that are not the same.
Have a brief read here. When a number is positive its two's complement representation corresponds to its "normal" binary representation, so when you want to convert a number (sign plus absolute value, any base):

• if it's positive you just convert its absolute value in binary form
• if it's negative you make the two's complement of its absolute value in binary form

When you want to come back things are just the same: you can tell the sign looking at the first bit: if it's zero the number is positive, if it's 1 it's negative. That's why the book tells you that these are 12 bits numbers, without that information you would have been right for both your answers.
So, to extend the bits passing through a sign-magnitude representation:

• if the msb is 1 convert the number as you did, add zeroes, go back to two's complement
• if the msb is 1 convert the number, i.e. keep it as is, add zeroes, go back to two's complement, i.e. keep it as is

And that's it. As Ignacio writes it happens that it's enough to just extend the MSB to the left (you can proof that starting from the formulas on wikipedia), but that's just a quick way to do things and does not explain why you were wrong. Keep his advice as a way on how to check your calculations... And (in the future) as the way to avoid errors.

-