# binary importance of - Why prefer two's complement over sign-and-magnitude for signed numbers?

Wikipedia says it all:

The two's-complement system has the advantage of not requiring that the addition and subtraction circuitry examine the signs of the operands to determine whether to add or subtract. This property makes the system both simpler to implement and capable of easily handling higher precision arithmetic. Also, zero has only a single representation, obviating the subtleties associated with negative zero, which exists in ones'-complement systems.

In other words, adding is the same, wether or not the number is negative.

I'm just curious if there's a reason why in order to represent -1 in binary, two's complement is used: flipping the bits and adding 1?

-1 is represented by 11111111 (two's complement) rather than (to me more intuitive) 10000001 which is binary 1 with first bit as negative flag.

Disclaimer: I don't rely on binary arithmetic for my job!

Two's complement allows addition and subtraction to be done in the normal way (like you wound for unsigned numbers). It also prevents -0 (a separate way to represent 0 that would not be equal to 0 with the normal bit-by-bit method of comparing numbers).

The usual implementation of the operation is "flip the bits and add 1", but there's another way of defining it that probably makes the rationale clearer. 2's complement is the form you get if you take the usual unsigned representation where each bit controls the next power of 2, and just make the most significant term negative.

Taking an 8-bit value a_{7} a_{6} a_{5} a_{4} a_{3} a_{2} a_{1} a_{0}

The usual unsigned binary interpretation is:

2^{7}*a_{7} + 2^{6}*a_{6} + 2^{5}*a_{5} + 2^{4}*a_{4} + 2^{3}*a_{3} + 2^{2}*a_{2} + 2^{1}*a_{1} + 2^{0}*a_{0}

11111111 = 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255

The two's complement interpretation is:

-2^{7}*a_{7} + 2^{6}*a_{6} + 2^{5}*a_{5} + 2^{4}*a_{4} + 2^{3}*a_{3} + 2^{2}*a_{2} + 2^{1}*a_{1} + 2^{0}*a_{0}

11111111 = -128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = -1

None of the other bits change meaning at all, and carrying into a_{7} is "overflow" and not expected to work, so pretty much all of the arithmetic operations work without modification (as others have noted). Sign-magnitude generally inspect the sign bit and use different logic.

Two's complement allows negative and positive numbers to be added together without any special logic.

If you tried to add 1 and -1 using your method

10000001 (-1)

+00000001 (1)

you get

10000010 (-2)

Instead, by using two's complement, we can add

11111111 (-1)

+00000001 (1)
you get

00000000 (0)

The same is true for subtraction.

Also, if you try to subtract 4 from 6 (two positive numbers) you can 2's complement 4 and add the two together 6 + (-4) = 6 - 4 = 2

This means that subtraction and addition of both positive and negative numbers can all be done by the same circuit in the cpu.

You can watch Professor Jerry Cain from Stanford explaining the two's complement, in the second lecture (the explanation regarding the 2's complement starts around 13:00) in the series of lectures called Programming Paradigms available to watch from Standford's YouTube channel. Here's the link to the lecture series: http://www.youtube.com/view_play_list?p=9D558D49CA734A02.

Well, your intent is not really to reverse all bits of your binary number. It is actually to subtract each its digit from 1. It's just a fortunate coincidence that subtracting 1 from 1 results in 0 and subtracting 0 from 1 results in 1. So flipping bits is effectively carrying out this subtraction.

But why are you finding each digit's difference from 1? Well, you're not. Your actual intent is to compute the given binary number's difference from another binary number which has the same number of digits but contains only 1's. For example if your number is 10110001, when you flip all those bits, you're effectively computing (11111111 - 10110001).

This explains the first step in the computation of Two's Complement. Now let's include the second step -- adding 1 -- also in the picture.

Add 1 to the above binary equation:

11111111 - 10110001 + 1

What do you get? This:

100000000 - 10110001

This is the final equation. And by carrying out those two steps you're trying to find this, final difference: the binary number subtracted from another binary number with one extra digit and containing zeros except at the most signification bit position.

But why are we hankerin' after this difference really? Well, from here on, I guess it would be better if you read the Wikipedia article.

It's worthwhile to note that on some early adding machines, before the days of digital computers, subtraction would be performed by having the operator enter values using a different colored set of legends on each key (so each key would enter nine minus the number to be subtracted), and press a special button would would assume a carry into a calculation. Thus, on a six-digit machine, to subtract 1234 from a value, the operator would hit keys that would normally indicate "998,765" and hit a button to add that value plus one to the calculation in progress. Two's complement arithmetic is simply the binary equivalent of that earlier "ten's-complement" arithmetic.

A major advantage of two's-complement representation which hasn't yet been mentioned here is that the lower bits of a two's-complement sum, difference, or product are dependent *only* upon the corresponding bits of the operands. The reason that the 8 bit signed value for -1 is `11111111`

is that subtracting *any* integer whose lowest 8 bits are `00000001`

from any other integer whose lowest 8 bits are `0000000`

will yield an integer whose lowest 8 bits are `11111111`

. Mathematically, the value -1 would be an infinite string of 1's, but all values within the range of a particular integer type will either be all 1's or all 0's past a certain point, so it's convenient for computers to "sign-extend" the most significant bit of a number as though it represented an infinite number of 1's or 0's.

Two's-complement is just about the only signed-number representation that works well when dealing with types larger than a binary machine's natural word size, since when performing addition or subtraction, code can fetch the lowest chunk of each operand, compute the lowest chunk of the result, and store that, then load the next chunk of each operand, compute the next chunk of the result, and store that, etc. Thus, even a processor which requires all additions and subtractions to go through a single 8-bit register can handle 32-bit signed numbers reasonably efficiently (slower than with a 32-bit register, of course, but still workable).

When using of the any other signed representations allowed by the C Standard, every bit of the result could potentially be affected by any bit of the operands, making it necessary to either hold an entire value in registers at once or else follow computations with an extra step that would, in at least some cases, require reading, modifying, and rewriting each chunk of the result.

because CPU manufacturers are lazy!