2's comp (1 Viewer)

[crammy90]

when we are asked to multiply 2 2's compliment numbers do we just do its outright because a number expresed in 2's compliment is equal it what it is not in 2's comp
so say we had to multiply the 4-bit number of -5 decimal with -2 decimal
5(dec) = 0101(base 2)
= 1011(2's comp) so this is -5
2(dec) = 0010(base 2)
= 1110(2's comp) so this is -2
(multiplying these 2's comp)
= 10011010 = 154(2's comp) hmm as its 4-bit do we take the first 4 bits
i.e. 1010 = 10(which would be in 2's comp)
= -102 (normal decimal)
EDITTED:::::after reading i have become aware that this number we are trying to achieve (-10) is outside the available 4-bit range of 2's comp (i.e. -3,4) so it has given us this stupid number.
lets do this calculation again in another range (lets say -15 to 16. 2^5 = 5bit will allow us to do this calculation).
again:
5(dec) = 00101(base 2)
= 11011(2's comp) so this is -5
2(dec) = 00010(base 2)
= 11110(2's comp) so this is -2
multiplying we get:
11011 x 11110 =
= 1100101010 = 810 (2's comp)
= -241 (normally)
what am i doing wrong lol

what did i do wrong?
confused








ALSO::

subtraction we find 2's comp of number being subracted and add to other number.
"If the number being subtracted is negative the leading bit is 0. We find the twos comp of this which will be positive and add"

WTF
i thought we were using 2's comp to express neg numbers. IF the number we are subtracting is a negative with a 1 doesnt that mean its a 2's compliment of a positive number?
and if the number being subtracted is a negative which we can derive from the leading bit being a 1 giving it a negative weighting, what form is the number in. If this number is just in regular 8 bit binary and the leading bit is a 1 doesnt this just represent 256 for that number?

 

[zvyx]

the first bit with your twos complement is correct; i.e.
1011 x 1110 = 10011010 = 1010 (ignoring overflow) = 10 (decimal)
You don't convert back, because as you said, 2's complement is a representation of a negative number. And you're not trying to achieve -10, you're trying to achieve 10 (negative number multiplied by negative number equals positive number) which is what you did successfully.

i'm not sure where you got that quote, so i'll try and clear it up:
computers actually can't subtract.
when you subtract, you're adding a number and the negative form of another number.
this negative number can be represented using 2's complement.
when you subtract using 2s complement and adding, inevitably you get an overflow which you discard (you seem to understand the overflow concept)
you do not reconvert the end result 'back' into 2s complement. the solution IS the solution.

Its important to know how 2's complement actually works (i.e. the car odometer analogy) so you can better understand this.

 

[crammy90]

the first bit with your twos complement is correct; i.e.
1011 x 1110 = 10011010 = 1010 (ignoring overflow) = 10 (decimal)

i see. i thought we only get rid of the overflow if its an addition?

You don't convert back, because as you said, 2's complement is a representation of a negative number. And you're not trying to achieve -10, you're trying to achieve 10 (negative number multiplied by negative number equals positive number) which is what you did successfully.

ok so we have -5. when do twos compliment to represent it as a negative number we get 1011. So, is this a completely different err i dont know how to word it. Like, i mean we know its a negative as we have done 2's compliment to get it. How does the CPU know it isnt a larger positive i.e. 1 + 2+ 8 = 11? is two compliment a whole different thing that the system can identify? or is it because it has a most significant bit of 1? but then wouldnt this be sign and modulus. so as you can see im really confused.
i understand the odometer thing
so using it:
from 0, 5 is 5 units away from 0 in the pos so its 0101 i.e. 5
Going the other side of 0, 5 units away into the negatives from 0 we get 0-5 which in a 4-bit binary is 11? i.e. because there 16 numbers in 4-bit binary (1111=15 + 1 for 0 = 16 numbers?? corect?) and so 11+5 =0 units from 0 and 0+5 = 5 units from 0? so really they are the same thing?

(like i understand if we are 5 units from 0 positive on a car odometer it is 5 and just say we went 5 in the negative from 0 this would be 995(if there was a range of 1000)

when you subtract using 2s complement and adding, inevitably you get an overflow which you discard (you seem to understand the overflow concept)
you do not reconvert the end result 'back' into 2s complement. the solution IS the solution.

so we dont just discard the overflow when adding normally, we also discard it:
a) when performing multiplication, additions, with at least 1 2's comp? or do both need to be 2's comp like the example we went through above.


thanks for responding it really helped me. ask if u need anything. Im generally better with the theory side of this topic.
And do u have an answer for my question in files? thats been bugging me all week. its in the main SDD forum

 

[zvyx]

i see. i thought we only get rid of the overflow if its an addition?

I'm pretty sure getting rid of the overflow applies to all arithmetic when dealing with 2's complement.

How does the CPU know it isnt a larger positive i.e. 1 + 2+ 8 = 11?

You're right, the CPU doesn't. What happens when you add -5 and 5? You get 0..
What happens when you add 11 and 5? You get 16. But 16 is 10000, and we're dealing with 4 bits, so 10000 -> 0000 -> 0. Thats where this overflow business comes in.

is two compliment a whole different thing that the system can identify?

nope its just a representation. its a convenient one because you can actually do arithmetic with it, unlike sign and modulus.

i understand the odometer thing
so using it:
from 0, 5 is 5 units away from 0 in the pos so its 0101 i.e. 5
Going the other side of 0, 5 units away into the negatives from 0 we get 0-5 which in a 4-bit binary is 11? i.e. because there 16 numbers in 4-bit binary (1111=15 + 1 for 0 = 16 numbers?? corect?) and so 11+5 =0 units from 0 and 0+5 = 5 units from 0? so really they are the same thing?

(like i understand if we are 5 units from 0 positive on a car odometer it is 5 and just say we went 5 in the negative from 0 this would be 995(if there was a range of 1000)

remember that when you're converting numbers into decimal, that is actually a representation itself.
0101 doesn't have to mean 5. It could be an instruction for the CPU.
We just make it 5 because its base 2 -> base 10 conversion.
so likewise, when you see 1011, you automatically convert it to 11 in your brain since you're most familiar with the base 2 -> base 10 representation.
However when you're dealing with 2's complement, which is another representation, you can't think of 1011 as 11 any more, but rather as -5.

so we dont just discard the overflow when adding normally, we also discard it:
a) when performing multiplication, additions, with at least 1 2's comp? or do both need to be 2's comp like the example we went through above.

You mean when both numbers are negative? Because if you're using 2's complement, then the whole question is based on 2's complement. It doesn't matter if one number is positive and the other is negative, or both are negative.

Think of 2's complement as a representation, rather than a way to just show negative numbers. You can still have positive numbers in a 2's complement question, its just that they won't be changed.

 

[zvyx]

Hmmm. A little bit of a tricky one here:
What happens if you multiply -4 with 5? You get -20. How do you manage overflow in this case?
-4 = 1100
5 = 0101
multiplying together, you get 0011 1100.
Take the first four bits, so you get 1100.

That is 2's complement for -4. It's definately not what we wanted. What went wrong?
When we look at -20, it is actually -16 + (-4). Since we are with the odometer analogy, we know that the limit is 1111 for 4 bits, or 15. When you get a 16, it means the odometre has gone around once already.

But if you try and take the first 5 bits (1 1100) you end up with -4 again.
Or the first 6 bits (11 1100) you end up with -4 again.

So with your huge numbers you received in your earlier example, by ignoring overflow, you were ignoring the number of times that the odometer had already gone over. We know that if you have a 6 digit limit odometer and it reads 000000, it could mean 0, or 1000000. But it also could mean 2 million, or 3 million.

I don't know what to make of this actually. I've never come across 2's complement for multiplication (I know, wtf?), only for subtraction. So its rather odd.

In answer to "when we are asked to multiply 2 2's compliment numbers do we just do its outright because a number expresed in 2's compliment is equal it what it is not in 2's comp" which I never really answered properly, two 2's complement numbers doesn't mean 2 negative numbers. It just means 2 numbers in 2's complement form. If you have 2 negative numbers, you can just write "two negatives equals a positive" and just proceed to do the equation normally, getting rid of the negatives.

I've also heard that you can get full, yes FULL marks, if you do all the working out for this section, and you know how to do it, but make a mistake somewhere and end up with the incorrect result. Supposedly, software markers makring this option are looking for people who know how to do it, not people who don't get confused when looking at a string of 1s and 0s. I know I get confused easily when doing massive binary multiplication (5 or 6 digit numbers)

 

[crammy90]

so when we do 5 - 4
0101 = 5
-4 = 0100
= 1100 (2's comp)
now if we add 0101 + 1100 this calculation (even though the 5 is in normal representation) is in 2's compliment (as one of the numbers is in 2's comp) so we must exclude the carry after 4 bits?
however if it was 5 + 5 we do not exclude the carry as it is in normal representation, not 2's compliment?
correct?
wow i had an epiphany (theyve been happening alot lately on here ahaha)
so i get you, i think
bare with me aha

0101 = 5 which is 5 units away from 0
1100 = -4 as it is really 12, which is 4 units away from 16 which is 10000 which as its 2's comp we discard carry and its 0.
so basically what i didnt understand was how 1100 could be the same as 0100. however now that i know about the overflow business i can see how the numbers tick over accordingly
you have been heaps of help aha thank you heaps lol

and
so with sign and modulus you cannot do any calculations?

p.s. why dont we use sign and modulus? is it because it needs that most significal bit which greatly reduces the range that number of bits can represent and so to store larger numbers requires more bits?

 

[zvyx]

excellent! yeh my teacher told me this option is probably the most difficult for those who don't understand difficult/complicated concepts easily, and it is true - i can see more than half of students attempting this option have difficulty doing binary arithmetic and the like.

yep, with sign and modulus, arithmetic just don't work.
lets take umm..
5 - 3
= 0101 + 1011 (leading bit 1 indicating negative number, and 011 being 3)
= 10000
= 0? problem

and since computing is very much based on arithmetic, it sort of negates a use for sign and modulus. still could be used for storing data though, and I guess its easy to see what number it is (without having to do the 2s complement business - for sign and modulus just look at all the bits cept the most significant and theres the number)

 

[Graceofgod]

*bump* (just for you crammy)

Yeah something here that both you and zvyx seemed to misunderstand about 2's comp.

The cpu DOES know whether it is a negative number or a really big postive number.
(As I explained in the negative minus negative thread earlier)

The first sign of a two's complement is whether it is positive or negative.
You were actually correct in your very first calculations, the error you made was that the result was out of the range. However when you fixed this you forgot to take out overflow.

5(dec) = 00101(base 2)
= 11011(2's comp) so this is -5
2(dec) = 00010(base 2)
= 11110(2's comp) so this is -2
multiplying we get:
11011 x 11110 =
= 1100101010 = 810 (2's comp)
= -241 (normally)
what am i doing wrong lol

What you should have actually done is:
11011 x 11110 =
1100101010 =
01010 (5 bit)
= +10

Lets say for example you had 5 and -2
5(dec) = 00101
-2(dec) = -00010 = 11110 (2's comp)
00101 x 11110 =
10010110 = 10110 (5 bits) (Which is negative due to starting bit '1')
= -01010 = -10(dec)