Suppose I have two signed binary which is:
A: 1100
B: 1000
And I want to subtract B from A.
After 2's complementing B, this would be:
1100 + 1000 = '1'0100
I thought that there would be an overflow from this because the sign for A and B is negative while the answer is positive, but my worksheet answer key says otherwise.
My question is, will the overflow be 1 or is the answer key mistaken?
There's no overflow in this computation.
1100 is -4 decimal.
1000 is -8 decimal.
-4 - (-8) = 4
So the result is 0100, without any overflow. (All the values involved are representable as signed-4-bit, which covers the range -8 to 7 inclusive.)
Note that subtraction never overflows (neither overflow, nor underflow) if the operands have the same sign, which is the case here.
It appears you're confusing the extra bit at the end of the addition with determining whether overflow happened. This simply isn't the case in general; for each operation there are different rules to determine if an overflow/underflow happened. Here's a good paper to read, which details the exact conditions under which underflow/overflow occurs for signed and unsigned binary arithmetic of bit-vectors: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/z3prefix.pdf
Related
I need a bit advice of the following topics: adding two signed/magnitude and adding two complement binary numbers. I did my calculations on paper and uploaded the picture. Sorry if my picture is sideways (I don't know why the upload does that)
Adding two signed/magnitude
+6 + (-6)
Ignore the carry 1. The sum is 4 and incorrect. No overflow because we have added two numbers with different signed indicators, 0 and 1.
+4 + (+5)
The sum is -1 and incorrect. Overflow because we because we have added two numbers with the same signed indicators 0.
Adding two complement binary numbers
+6 + (-6)
Ignore the carry 1. The sum is 0 and correct. No overflow because we have added two numbers with different signed indicators, 0 and 1.
+4 + (+5)
The sum is -7 and incorrect. Overflow because we because we have added two numbers with the same signed indicators 0.
Did I understand correctly about binary addition overflow and sum correctness though my examples?
From this University course
4.11.4. Addition and Subtraction
Addition and subtraction require attention to the sign bit. If the signs are the same, we simply add the magnitudes as unsigned numbers and watch for overflow. If the signs differ, we subtract the smaller magnitude from the larger, and keep the sign of the larger.
So for sign-magnitude you got the first one wrong.
The signs differ so you subtract the larger from the smaller. As they are the same, it doesn't matter what you pick. The result is 0 and it is correct. +0 or -0. It doesn't matter as they both represent the same thing.
You got the second one wrong too because for the sum +4+5, you should keep the sign + for the result and then add the magnitude. Which is
1 carry (ignore carry to the most sign bit)
0100 +4
0101 +5
--------
0001 +1
The result is +1 and there was an overflow that was detected by the carry out to the most significant bit, which is the sign bit.
Check this for more info http://pages.cs.wisc.edu/~smoler/x86text/lect.notes/arith.int.html
2's complement
Your answers are correct :tada:
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
for my computer science class I need to finish a project where I desperately need to understand logic of one´s complement and two´s complement. I already know how to construct these and also how hardware adder works when dealing with two´s complement. The thing that is bothering me and I need help with is the logic behind one´s complement addition. Why do we have to add the bit we would carry over (and discard when using two complement coding) to the sum to get the correct result? I don´t understand why binary addition behaves like this when adding one´s complement and why is that last adding of carry over bit so crucial. I need to understand the logic behind it. Thanks
A 1's complement number (say,16 bits) can be described as below - in terms of the relationship between the binary code c (which is 0..0xFFFF, or 0..65535) and the 'value' x which the code represents, x is in range -32767.. 32767.
if the value x is 0..32767, the code c is numerically equal to x, and thus has a zero in the MSB
if the value x is negative, -1 .. -32767, then c is 65535 - x, and the MSB of c is 1.
The code c=65535 = 0xFFFF is to be interpreted as zero; since it has a 1 in the MSB I will call it '-0'.
Now consider what happens to the x values when you add two codes using a a binary adder:
If both x1, x2 are positive, the adder adds the codes: c = c1 + c2. both MSBs are zero at the input, so there will be no carry. So the value of c will be the sum x1+ x2 and this is how it will be interpreted (assuming the sum doesn't overflow into the MSB).
If both x1, x2 are negative, then by adding c1+c2 you are adding (65535+x1)+(65535+x2). There will always be a carry-out; by discarding this you end up with a binary value equal to 65534+(x1+x2). To get the code we want to represent this negative sum, i.e. 65535+(x1+x2), we need to add 1 more.
If the signs are different, the sum of codes is 65535+(x1+x2). There may or may not be a carry-out. Since the MSBs are different, the carry-out occurs if, and only if, the MSB of the sum is zero. In the case where the true sum (x1+x2) < 0, you won't have a carry-out, and the value 65535+(x1+x2) is the proper code for (x1+x2). If the sum (x1+x2)>0, there will be a carry-out; the sum of the codes (after discarding the carry out) will be (x1+x2)-1, and thus you have to add 1 to get the proper code (x1+x2).
So, looking at all the cases, it works out that whenever a carry-out occurs, (and you effectively subtract 65536 by discarding it) you need to add 1 to get the proper code to represent the sum.
When x1+x2 = 0 -- with one <0 and the other >0 - the sum of codes will always be 65535, which is left as is and is to be interpreted as zero ("-0").
When both are zero, you have three cases:
0 + 0 = 0 Fairly simple...
-0 + -0: codes are 0xFFFF + 0xFFFF = (carry+ 0xFFFE) = 0xFFFF after adding carry back in, interpreted as -0.
-0+ 0: codes are 0xFFFF + 0 = 0xFFFF (-0)
So the only case where the 1's complement sum is a 'proper' 0 is when both inputs are proper 0. All other cases adding up to zero give a '-0'.
Mathematically, you could say that 1's complement uses (c = x) mod 65535, with c constrained to 0...0xFFFF. And so the addition needs to be done modulo 65535. Each time you have a carryout, you subtract 65536 (by discarding it from the top) and add 1 (by adding it at the bottom); since you subtract 65535 in the process, the modulo 65535 value is preserved.
I'm trying to wrap my head around overflow within twos complement for example say I'm trying to take away these two binary numbers:
1111 1000 0100 - 010 111 001 000
I convert the 2nd binary number to it's two complement equivalent and then simply add it but I noticed it resulted in an overflow of 1, do I simply ignore the overflow? or is there a rule I must follow
1111 1000 0100 + 1010 0011 1000 = (1) 1001 1011 1100
Short answer:
if you are performing arithmetic on fixed-width binary numbers, using two's complement representation for negative numbers, then yes, you ignore the one-bit overflow.
Long Answer:
You can consider each ith bit in n-bit two's complement notation have place value 2^i, for 0 <= i < n - 1, with bit n - 1 (the sign bit) having place value -2^(n - 1). That's a negative place value for the sign bit. If you compute the sum of two such numbers as if they were unsigned n-bit binary numbers, these cases are fine:
the sign bit is not set in the either addend or in the result (reinterpreted as being in two's-complement representation),
the sign bit is set in exactly one of the addends, regardless of overflow (which is ignored if it occurs), or
the sign bit is set in both addends (therefore there is an overflow, which is ignored) and in the result.
To understand that, it may be easier to think about the problem as two separate sums: a sum of the sign bits, and a sum of the value (other) bits. An overflow of the value sum yields an overflow bit whose place value is 2^(n-1) -- exactly the inverse of the place value of a sign bit -- therefore such an overflow cancels one sign bit.
The negative + negative case requires such a cancellation for the result to be representable (two sign bits + one value overflow = one sign bit), and the positive + positive case cannot accommodate such a cancellation because there is no sign bit available to be cancelled. In the positive + negative case, there is an overflow of the value-bit sum in exactly those cases where the result is non-negative; you can consider that to cancel the sign bit of the negative addend, wich yields the same result as ignoring the overflow of the overall unsigned sum, and reinterpreting the sum as a two's complement number.
The remaining cases yield mathematical results that cannot be represented in n-bit two's complement format -- either greater than the largest representable number, or less than the smallest. If you ignore overflow then such results can be recognized by an apparent sign flip. What you do with that is a question of error recovery strategy.
From Wikipedia's article on 2's complement in the section on addition at https://en.wikipedia.org/wiki/Two%27s_complement#Addition, my understanding is that carry beyond the given (fixed) bit length (to the left) can be ignored but not overflow as determined when the leftmost two bits of the carry are different. The article shows how to maintain a carry row so as to tell if there was overflow and here is a simple example in the same style:
In 4 bit 2's complement -2 is 1110 and +3 is 0011 so
11110 carry
1110 -2
+0011 +3
----
10001 which is 0001 or simply 1 ignoring the carry in bit 5 and is
safe since the leftmost two bits in the carry row are identical
Although this is a very old question, it comes up frequently. In two's complement addition, a carry out from the leftmost digit is discarded. Why? Although not precisely correct mathematically, it is easiest to think of a two’s complement number as having a sign bit on the left and value bits elsewhere. The only way a carry out of the sign bit can occur is if the sign bits of both addends were one (negative) and there was a carry in to the sign bit. In that case, the sign bit of the result will be one, which is correct. A problem occurs if the carry in to the sign bit is different from the carry out. That causes an incorrect sign bit, which is an overflow condition. That can be detected without referring to the carry out from the sign bit because the sign of the result will be wrong. For example, if two positive numbers are added and the result is negative, something is wrong. The something that’s wrong is that the sum of the value bits has overflowed into the sign bit and the result is in error.
With pen and paper arithmetic, it is usual to discard the carry and check that the sign of the result is correct. In electronic circuits, the easiest way is to compare that carry in to the carry out with an XOR and signal an error if they differ. The carry out is not otherwise used or stored.
Im doing this question and some clarification would be super helpful. What exactly would an overflow entail? If when converting to decimal notation an extra bit would be needed? Fro part 3 "consider the bits as two's complement numbers" does he mean find the 2's complement? Thanks a bunch.
For number 3 he does not mean find the 2's complement. He is telling you to treat the values as signed numbers using 2's complement notation. That would mean the first value in a) is positive and the other three are negative.
For overflow it is different for 2 and 3. For 2, unsigned numbers, overflow occurs if there is a carry out of the high bit. For 3, 2's complement signed numbers, overflow occurs if the sign of the result is not correct. For example, if you add two positive numbers and the result is negative, there was overflow.
If you add x and y and get a result that is less than x or less than y, then the addition has overflowed (wrapped-around).
An overflow would be if the resulting sum is a larger number than can be expressed in an 8 bit system. I believe that would be any number greater than 255 (1 << 8).
Your assumption "an extra bit" is mostly correct. In an 8 bit system, all numbers are stored in 8 bits. Any operation that results in a number greater than the maximum that can be represented will be an overflow. This doesn't happen when you convert to decimal, but when you actually perform the sum with the binary values. If all numbers are 8 bits, you can't just add an additional bit when you need to store a larger number.
Yes, "two's complement" is the same as "2's complement". I'm not aware of any distinction between whether you spell it out or use the numeral.
I'm watching some great lectures from David Malan (here) that is going over binary. He talked about signed/unsigned, 1's compliment, and 2's complement representations. There was an addition done of 4 + (-3) which lined up like this:
0100
1101 (flip 0011 to 1100, then add "1" to the end)
----
0001
But he waved his magical hands and threw away the last carry. I did some wikipedia research bit didn't quite get it, can someone explain to me why that particular carry (in the 8's ->16's columns) was dropped, but he kept the one just prior to it?
Thanks!
The last carry was dropped because it does not fit in the target space. It would be the fifth bit.
If he had carried out the same addition, but with for example 8 bit storage, it would have looked like this:
00000100
11111101
--------
00000001
In this situation we would also be stuck with an "unused" carry.
We have to treat carries this way to make addition with two's compliment work properly, but that's all good, because this is the easiest way of treating carries when you have limited storage. Anyway, we get the correct result, right :)
x86-processors store such an additional carry in the carry flag (CF), which is possible to test with certain instructions.
A carry is not the same as an overflow
In the example you do have a carry out of the MSB. By definition, this carry ends up on the floor. (If there was someplace for it to go, then it would not have been out of the MSB.)
But adding two numbers with different signs cannot overflow. An overflow can only happen when two numbers with the same sign produce a result with a different sign.
If you extend the left-hand side by adding more digit positions, you'll see that the carry rolls over into an infinite number of bit positions towards the left, so you never really get a final carry of 1. So the answer is positive.
...000100
+...111101
----------
....000001
At some point you have to set the number of bits to represent the numbers. He chose 4 bits. Any carry into the 5th bit is lost. But that's OK because he decided to represent the number in just 4 bits.
If he decided to use 5 bits to represent the numbers he would have gotten the same result.
That's the beauty of it... Your result will be the same size as the terms you are adding. So the fifth bit is thrown out
In 2's complement you use the carry bit to signal if there was an overflow in the last operation.
You must look at the LAST two carry bits to see if there was overflow. In your example, the last two carry bits were 11 meaning that there was no overflow.
If the last two carry bits are 11 or 00 then no overflow occurred. If the last two carry bits are 10 or 01 then there was overflow. That is why he sometimes cared about the carry bit and other times he ignored it.
The first row below is the carry row. The left-most bits in this row are used to determine if there was overflow.
1100
0100
1101
----
0001
Looks like you're only using 4 bits, so there is no 16's column.
If you were using more than 4 bits then the -3 representation would be different, and the carry of the math would still be thrown out the end. For example, with 6 bits you'd have:
000100
111101
------
1000001
and since the carry is outside the bit range of your representation it's gone, and you only have 000001
Consider 25 + 15:
5+5 = 10, we keep the 0 and let the 1 go to the tens-column. Then it's 2 + 1 (+ 1) = 4. Hence the result is 40 :)
It's the same thing with binaries. 0 + 1 = 1, 0 + 0 = 0, 1 + 1 = 10 => send the 1 the 8-column, 0 + 1 ( + 1 ) = 10 => send the 1 to the next column - Here's the overflow and why we just throw the 1 away.
This is why 2's complement is so great. It allows you to add / substract just like you do with base-10, because you (ab)use the fact that the sign-bit is the MSB, which will cascade operations all the way to overflows, when nessecary.
Hope I made myself understood. Quite hard to explan this when english is not you native tongue :)
When performing 2's complement addition, the only time that a carry indicates a problem is when there's an overflow condition - that can't happen if the 2 operands have a different sign.
If they have the same sign, then the overflow condition is when the sign bit changes from the 2 operands, ie., there's a carry into the most significant bit.
If I remember my computer architecture learnin' this is often detected at the hardware level by a flag that's set when the carry into the most significant bit is different than the carry out of the most significant bit. Which is not the case in your example (there's a carry into the msb as well as out of the msb).
One simple way to think of it is as "the sign not changing". If the carry into the msb is different than the carry out, then the sign has improperly changed.
The carry was dropped because there wasn't anything that could be done with it. If it's important to the result, it means that the operation overflowed the range of values that could be stored in the result. In assembler, there's usually an instruction that can test for the carry beyond the end of the result, and you can explicitly deal with it there - for example, carrying it into the next higher part of a multiple precision value.
Because you are talking about 4 bit representations. It's unussual compared to an actual machine, but if we were to take for granted that a computer has 4 bits in each byte for a moment, then we have the following properties: a byte wraps at 15 to -15. Anything outside that range cannot be stored. Besides, what would you do with an extra 5th bit beyond the sign bit anyway?
Now, given that, we can see from everyday math that 4 + (-3) = 1, which is exactly what you got.