Lecture 5/12: Sign Extension

[@v1ct0rx24]

you're a wizard harry

[@anondoggo]

Thank you prof. You are saving lives.

[@Brlitzkreig]

Yes, he really is!

[@IulianOnofrei]

How do you know to stop at the previous to the last "1"? Why isn't "100 0101" the shrinked value of "1111 1111 1111 1111 1111 1111 1100 0101"?

[@marekrimal2371]

I think that is because of the byte size. It must contain 8 bits, not 7. If you write 100 0101 so that technically means 0100 0101.

[@archidar1]

Binary 1111 is equal to Decimal -1. This is an important thing to note, that in negative, you are counting up to 1111. Therefore, 110101 (53) has the exact same negative value as 1111 110101 (1013), because they are both the same distance away from 111111 (63) and 1111 111111 (1023) respectively. The first case (110101) is 10 values away from 111111, thus it is -11 The second case (1111 110101) is 10 values away from 1111 111111, thus it is -11 This carries on for however many values of 1 you place at the front. What you are counting isn't the binary number itself, what you are counting is how far away the binary number is from -1 (aka 1111 ... 1111). This is because everytime you extend the length of the binary 1s, while you are doubling its possible negative numerics, you are also adding that number back. Example: 1011 (Eleven) = -5 Because it is 4 digits away from 1111 (Fifteen) which would be -1 (COS 1111...1111 IS ALWAYS -1) Compare the above to what happens when we expand the front 1s: 1111 1011 (251) = -5 Because it is still 4 digits away from 1111 1111 (255) This is because while 1000 0000 (128) is now = -128, once we add in the buffer ones it becomes 1111 0000 (240), which is -16 because it is 15 values away from 1111 1111 (255) We now add the original number back in: 1111 1011 = -5. This shows that though the length increase of bits causes the initial negative to be larger (from 1000 being = -8 to 1000 0000 being -128) the buffer 1s cause the overall extension to cancel out its effect, so the original number will always be the same distance away from -1, with or without the initial ones. Since the distance between the number and -1 is what we are concerned with for negative numbers, the buffer doesn't matter.

[@regisjosefazoulay5854]

10:10 "a char is a bits" => mispelling, it's a "byte" (8 bits) right ?

[@kitty_kee]

No! He said "A char is 8 bits".

[@regisjosefazoulay5854]

@@kitty_kee ah ok maybe a misuderstanding of the english accent....thx

[@spirridd]

24:38 "both of these are converted to signed numbers" Why not to unsigned?

[@marekrimal2371]

How do I know whether it is sign extended or just a really big negative number? How do I distinguish these two numbers after the extension (to 4 bytes for example): 1101 1010 1111 1111 1101 1010

[@archidar1]

Binary 1111 is equal to Decimal -1. This is an important thing to note, that in negative, you are counting up to 1111. Therefore, 110101 (53) has the exact same negative value as 1111 110101 (1013), because they are both the same distance away from 111111 (63) and 1111 111111 (1023) respectively. The first case (110101) is 10 values away from 111111, thus it is -11 The second case (1111 110101) is 10 values away from 1111 111111, thus it is -11 This carries on for however many values of 1 you place at the front. What you are counting isn't the binary number itself, what you are counting is how far away the binary number is from -1 (aka 1111 ... 1111). This is because everytime you extend the length of the binary 1s, while you are doubling its possible negative numerics, you are also adding that number back. Example: 1011 (Eleven) = -5 Because it is 4 digits away from 1111 (Fifteen) which would be -1 (COS 1111...1111 IS ALWAYS -1) Compare the above to what happens when we expand the front 1s: 1111 1011 (251) = -5 Because it is still 4 digits away from 1111 1111 (255) This is because while 1000 0000 (128) is now = -128, once we add in the buffer ones it becomes 1111 0000 (240), which is -16 because it is 15 values away from 1111 1111 (255) We now add the original number back in: 1111 1011 = -5. This shows that though the length increase of bits causes the initial negative to be larger (from 1000 being = -8 to 1000 0000 being -128) the buffer 1s cause the overall extension to cancel out its effect, so the original number will always be the same distance away from -1, with or without the initial ones. Since the distance between the number and -1 is what we are concerned with for negative numbers, the buffer doesn't matter.

[@anondoggo]

@@archidar1 Thank you! I had the same question and this is so helpful!

[@jasonmiller6424]

5:35 why is 8-F negative and 0-7 positive in hex?

[@ginicholas4322]

change it to binary and you'll see

[@MattyMatiss]

I did't know that the insignificant part in negative numbers is filled with 1s and Fs. Thank you for the lesson

[@Folsets]

Hi! How the computer knows whether an integer is signed or unsigned?

[@kitty_kee]

Basically you have to tell computer. Integer is signed by default so if you have to declare unsigned number or you want to typecast then you have to use *unsigned* keywords. Hope you will be satisfy by my answer.

[@goldfish8196]

THANK YOU.

[@飴旨]

去去武器走

[@sharathchandra6349]

Tw

[@asdsa7434]

You sound like Trump