1's and 2's complement of the following binary numbers 10101110?

Answer 1

The question has to do with the way how whole numbers are to be represented in binary notation, and in particular how negative numbers should be coded.

In the above question, the number has 8 binary digits (bits), allowing exactly 256 different combinations to be used, from 00000000 to 11111111. If we consider only positive numbers, this would allow for all numbers from 0 (naturally represented by 00000000) to and inclusively 255 (represented by 11111111).

Now if you want to take negative numbers into account, there is a problem. The most obvious solution is to spare the first bit as a sign indicator, thus leaving the 7 last bits to represent the numbers. This way was chosen in the early days of FORTRAN, one of the first popular programming languages. This simple way to represent negative numbers has for it the equally simple way to compute the negative of a given number: just invert the first bit!. Hence, the number 3, for example, represented as (00000011) will give (10000011) for -3 (we have just toggled the first bit).

This simple way has a drawback: the negative of 0 (00000000) is now (10000000), known as -0 by FORTRANists. But, as everyone knows, except perhaps the thermometer indicator in you car, which ostensibly uses this notation, -0 and +0 are the same number, at least according to arithmetic rules teached in the primary school.

But if you consider their binary representations, they differ. Hence, in some cases, two arithmetical results everyone consider equal can be judged different by a FORTRAN program, leading to strange results (this is clearly a bug that is very difficult to pinpoint). Moreover, this strange behavior will disappear if you reorder your computations, thus violating the commutativity rules everyone expects from whole number arithmetic

This way of representing negative numbers is known as the one's complement notation. Hence, the 1's complement to the number mentioned in the question is 01010001, corresponding to 81 in decimal notation.

To solve the above -0 problem, modern computers and programming languages have adopted another representation, the so-called 2's complement. The idea is to sacrifice the simple symmetry of the one's complement notation by specifying that the computation of the negative of a given number must be done by inverting each bit (inclusively the sign bit) and adding 1 to the result.

For example, if you consider the number 3 (00000011), its negative, or 2's complement, is (11111101) (all bits inverted and 1 added (possibly leading to carries that must be handled properly). If you take 0 (00000000), its negative would be (11111111 + 00000001), giving (00000000) plus an overflow carry on the first bit that is ignored, but the net effect is that the negative of 0 is still 0, as everyone would expect.

The glitch in the above computation is that there now exists a negative number without positive counterpart Consider 10000000. This should be interpreted as -128, because it is -127 (10000001) from which 1 has been subtracted. But +128 cannot be represented, nor computed. If you apply the above negation algorithm to -128, you obtain again 10000000, that is -128 itself. Looks like the trick that solves the negative of 0 problem just generates a new problem at the other end of the number spectrum.

On the other end, if you consider computer arithmetic in general, you should always take overflow problems into account, because computer numbers have only a limited precision or magnitude, determined by the number of bits you are using to represent your numbers. The above problem is exactly the same if you extend your arithmetic representation to 16, 32 or even 64 bits. If you add two big numbers and the result is too large for your representation, then you should raise an overflow exception.

Most computers just don't do that for efficiency reasons, because checking for the overflow may be as costly as the computation itself, and nobody is willing to sacrifice 50% of his computing power just to check for exceptions that nearly never arrive (but just nearly, not absolutely never). Hence it is the programmer's responsibility to ensure that his computations remain in the allowed arithmetic range.

Some strange bugs may naturally arise if your computer considers -128 and +128 to be the same number, as will be the case with the 2's complement notation on an 8 bits computer, but this is considered less harmful (not harmless!) than considering +0 and -0 as different numbers.

With modern 32 bits computers, the problem arises only with (approximately) +2 billions and -2 billions, hence the arithmetic range is considered big enough to neglect the problem in everyday cases.

So modern binary computers all use the 2's complement notation. Coming back to the original question, the 2's complement of the given number will be 01010010, corresponding to 82 in decimal notation

Summary

1's complement: 10101110 -> 01010001 (81 in decimal)

2's complement: 10101110 -> 01010010 (82 in decimal)

Answer 2

2's complement is very simple. 1st take 1's complement of the number and than add 1 to it.

No= 010100110

1's= 101011001

+1

2's=101011010.

so 2's complement is 101011010.

for programming visit Codes Mesh.