If I have got 1101 0010 0010 0010 on a 16bit system and want to convert it to decimal the result is -11,742 (teacher told me)
But if I enter the binary number into my calculator I get 53794.
Why is this the case? How does the system (8bit, 16bit, 32bit, 64bit) affect this?
I tried to convert the binary number with hand (2+32+512+4096+16384+32768 = 53794) but only to confirm my calculator....
It's because computer arhitmetic is based on two's complement
You shoud read about method of colpement
For example in complement decimal number natural subtraction looks like that (using 4 digits):
0000
0001 -
9999 =
It's obviously -1 because in complemental system first digit (in big endian of course, you shoud be familiar with endianness) defines sign. For example in decimal complement 4 is 4, 4 is 4, 3 is 3, 2 is 2, 1 is 1, 0 is 0, 9 is -1, 8 is -2, 7 is -3, 6 is -4 and 5 is -5.
It's because in complement number system you always operate on same number of digits but you are adding and substracting as always except ignoring overflowing result. For example with two decimal digits:
04
05 -
...9999 =
As I told result are only two digits (we added two digits) so the result is 99. As I also mentioned before first number is interpreted as -1 (not 9). Because it is positional number system we can easy convert this result to our normal decimal system just summing digits multypling by correct power's of ten:
10^1 * 9 + 10^0 * 9
//as I told - first nine is -1 so:
10^1 * -1 + 10^0*9 = -10 + 9 = -1
Now try with first result:
9999 = 9 * 10^3 + 10^2 * 9 + 10^1 * 9 + 10^0 * 9
//first nine is -1 so:
-1 * 10^3 + 999 = -1000 + 999 = -1
Now in binary it is much simpler because first number just tells as what sign is. Try with 8 bit number:
1111 1111
It's obviously -1 because if we add 1 the result will be 0. You may say I'm laying becaus you can simply make following addition:
1111 1111
0000 0001 +
1 0000 0000 =
But it's not correct in complement system. It's because in complement system first digit not only describe sign of number but also all number can be infinitly expanded by that digit! It's why id complement decimal 99 = 9999 ! It also means that we can easy expand 8 bytes number to for example 32 bytes!
For example try with numbers 17 and -1. You are now familiar with -1. In 8 bytes two's complemex -1 is:
1111 1111
Expanded to 32 bytes it gives us:
1111 1111 1111 1111 1111 1111 1111 1111
To convert it to normal decimal system we need to do 2^31 + 2^30 + ... + 2^0 but (as I mentioned) first 1 is -1 so it's exactly -1 * 2^31 + 2^30 + .. + 2^0 if you compute this it's exactly -2147483648 + 2147483647 = -1 !
0001 0001 (decimal 17)
Expanded to 32 bites gives:
0000 0000 0000 0000 0000 0000 0001 0001
And we can agree it's still 17 :)
To provide I'm not some crazy, just IT student I'm going to present C++ code that does exactly that stuff:
#include <iostream>
using namespace std;
int main(void)
{
char eightBits = 255; //eightBits := 0x11111111
int eightBytes = eightBits; //eightBytes becaming 255, right?
cout <<eightBytes <<endl; // MAGIC !
return 0;
}
Basically, it depends on how much space there is. The most significant bit is used to determine whether or not the number is negative.
In a 32-bit system, the two following numbers are equivalent:
1101 0010 0010 0010
0000 0000 0000 0000 1101 0010 0010 0010
As a signed 16-bit value, the 1 at the beginning denotes that it's a negative number. To get its value, flip each bit, then add one.
1101 0010 0010 0010
0010 1101 1101 1101
0010 1101 1101 1110
= 11742
As an unsigned 16-bit value, all sixteen bits are used to determine the magnitude. This would result in 53794.
Reference
The unpoken bit here is about the sign. It is stored on the front end and denotes the sign.
http://www.binaryconvert.com/result_signed_short.html?decimal=045049049055052050
More succinctly, a 16bit 'word' or integer is usually called a 'short' on most systems and represents signed number between −32,768 and +32,767. This is the 'binary' number to which your teacher is referring, which is not stored directly as a binary number, but in binary format. There are actually only 15 spots to store the value and one that must be reserved for the sign. Otherwise, an unsigned value can use all 16 spots for numbers and thus can go to from 0 to +65,535.
There are different ways to represent binary numbers:
Unsigned (what you are doing)
Signed
1's complement
2's complement (what you are supposed to do according to your teacher)
Digital systems generally use 2's complement representation.
To get decimal number for a binary number in 2's complement:
1. First bit is the sign bit. If the number starts with 0, it is positive, otherwise it is negative.
2. If the number is positive, its decimal value is unsigned value of the remaining bits other than the sign bit. If the number is negative, its absolute decimal value = (signed value of the complement of the remaining bits)+1.
In computers, it is common to represent "two's complement" signed numbers by assuming that the leftmost bit is duplicated an infinite number of times, so that the bit sequence (1101 0010 0010 0010) is regarded as (1111....1111 1101 0010 0010 0010). Although an infinite string of ones may seem like an infinitely large number, adding one to such a string will yield an infinite string of zeroes (i.e. 0). Thus, an infinite string of ones is the additive inverse of 1, and thus has an effective value of -1. An infinite string of ones followed by some number of zeroes, will be the additive inverse of a single 1 followed by that number of zeroes (so in your example, the leftmost "1" has an effective value of -32768 rather than +32768). While the fact that applying the power-series formula to 1+2+4+8+16+32+64... yields -1 is often regarded as an anomaly, it is consistent with the way that "two's complement" math works.
Note that while many descriptions of two's complement math simply describe the sign of the uppermost bit's "scaling factor" as being inverted (e.g. -32768 rather than +32768), thinking in terms of left-padding with copies of the leftmost bit makes it easier to understand why signed numbers behave as though the leftmost number is duplicated (e.g. converting a negative 16-bit integer to a 32-bit integer fills the leftmost 16 bits with ones).
Related
if I convert the binary number 000000 into 2's compliment I will get
1's compliment (invert) = 111111
2's compliment (add +1) = here I run into a problem, does this return 000000 and the 1 gets discarded or does this return 1000000?
Thanks in advance!
It discards the 1. The condition is similar to the Arithmetic Overflow.
Strength of two's complement is that it helps us retain a binary representation when signed numbers are to be considered, because in mathematics, the value of 0 is same as that of -0. If we have to give up one entire bit just for sign, then, in a 4-bit word, 0000 would denote 0 and 1000 would denote -0, wasting one representation. The two's complement helps get rid of this. If we assume 4-bit words:
val -val bits of val two's complement bits of -val (1's complement + 1)
0 0 0000 0000 (1111+0001)
1 -1 0001 1111 (1110+0001)
2 -2 0010 1110 (1101+0001)
3 -3 0011 1101 (1100+0001)
...
7 -7 0111 1001 (1000+0001)
8 -8 (no rep) 1000 (0111+0001)
(note that for -8 you have one's complement of 8 in an unsigned manner, i.e.8 = 1000 and hence its one's complement is 0111).
Thus you gain a representation for -8 by making 0 and -0 have the same bit pattern, i.e. 0000. Using this, for n bits, we can represent all integer values between -2^(n-1) to 2^(n-1)-1.
Hey guys I'm still trying to get the hang of twos complement arithmetic and I can get the correct answer, since I'm working on practice problems with solutions.
When I take the answer that's in binary, I can't seem to equate it out to the decimal answer before applying twos complement and adding the numbers.
000100-111001 In decimal it's 4 - 57= -53
Becomes
0001000+000111 which would be 4 + (-57)?
Giving a solution of 001011
How can 001011 be proven as equaling -53?
Thanks!
To answer your question, first 001011 is not equal to -53. This is the wrong answer. We know it must be positive since the highest order bit is a 0, not a 1. 001011 is actually equal to 11 (in base ten).
Let's do 4 - 57 now as an example. This is the same as 4 + (-57). Converting to binary (I will use just a byte for this example) we get: 4 is 0000 0100, 57 is 0011 1001. To convert 57 to negative 57 use two's complement:
1. Negate it: 1100 0110
2. Add one: 1100 0111So now we get the following equation:
0000 0100
+ 1100 0111
------------
1100 1011
We achieve the answer by simply adding down the rows. The answer we have gotten is 1100 1011. We know it is negative because the highest order bit (which here is leftmost) is a 1. To find its magnitude, we apply two's complement:
1. Negate: 0011 0100
2. Add one: 0011 0101
And this is equal to 53 in base ten.
Another way to see if it is correct is to add it with the positive version of the number.
1100 1011
+ 0011 0101
------------
10000 0000
Since two's complement is defined as the number subtracted from 2^n where n is the number of bits, you will always get this result for the sum. Knocking off the 1s digit it's interesting how what remains is just 0 - and any number plus its negative is zero.
I have answered the question but i could not understand the part where its says get the resulting sum in 16-bit binary, check your answer by converting the sum into decimal.
1.Add ‘A’ and ‘B’ in binary to get the resulting sum in 16-bit binary, check your answer by converting the sum into decimal.
Decimal number = 58927634
A= 5892 to Binary 1011 1000 0010 0
B= 7634 to Binary 1110 1110 1001 0
a + b = 11010011010110
thanks alot
Regards
Let me explain:
A = 00005892
B = 00007634
in base 10 number system, with 8 decimals to represent it.
and...
A = 0001 0111 0000 0100
B = 0001 1101 1101 0010
in base 2 number system, with 16 bits to represent it.
I hope it makes sense to you now.
And the sum of A and B, in base 2 number system with 16 bits to represent it....
0011 0100 1101 0110
although, we needed just 14 bits....
Your answer is correct, but its width is 14 bits long.
How would I go about manually changing a decimal (base 10) number into IEEE 754 single-precision floating-point format? I understand that there is three parts to it, a sign, an exponent, and a mantissa. I just don't completely understand what the last two parts actually represent.
Find the largest power of 2 which is smaller than your number, e.g if you start with x = 10.0 then 23 = 8, so the exponent is 3. The exponent is biased by 127 so this means the exponent will be represented as 127 + 3 = 130. The mantissa is then 10.0/8 = 1.25. The 1 is implicit so we just need to represent 0.25, which is 010 0000 0000 0000 0000 0000 when expressed as a 23 bit unsigned fractional quantity. The sign bit is 0 for positive. So we have:
s | exp [130] | mantissa [(1).25] |
0 | 100 0001 0 | 010 0000 0000 0000 0000 0000 |
0x41200000
You can test the representation with a simple C program, e.g.
#include <stdio.h>
typedef union
{
int i;
float f;
} U;
int main(void)
{
U u;
u.f = 10.0;
printf("%g = %#x\n", u.f, u.i);
return 0;
}
Take a number 172.625.This number is Base10 format.
Convert this format is in base2 format
For this, first convert 172 in to binary format
128 64 32 16 8 4 2 1
1 0 1 0 1 1 0 0
172=10101100
Convert 0.625 in to binary format
0.625*2=1.250 1
0.250*2=.50 0
0.50*2=1.0 1
0.625=101
Binary format of 172.625=10101100.101. This is in base2 format 10101100*2
Shifting this binary number
1.0101100*2 **7 Normalized
1.0101100 is mantissa
2 **7 is exponent
add exponent 127 7+127=134
convert 134 in to binary format
134=10000110
The number is positive so sign of the number 0
0 |10000110 |01011001010000000000000
Explanation:
The high order of bit is the sign of the number.
number is stored in a sign magnitude format.
The exponent is stored in 8 bit field format biased by 127 to the exponent
The digit to the right of the binary point stored in the low order of 23 bit.
NOTE---This format is IEEE 32 bit floating point format
A floating point number is simply scientific notation. Let's say I asked you to express the circumference of the Earth in meters, using scientific notation. You would write:
4.007516×107m
The exponent is just that: the power of ten here. The mantissa is the actual digits of the number. And the sign, of course, is just positive or negative. So in this case the exponent is 7 and the mantissa is 4.007516 .
The only significant difference between IEEE754 and grade-school scientific notation is that floating point numbers are in base 2, so it's not times ten to the power of something, it's times two to the power of something. So where you would write, say, 256 in ordinary human scientific notation as:
2.56×102 (mantissa 2.56 and exponent 2),
in IEEE754, it's
1×28 — the mantissa is 1 and the exponent is 8.
What is the binary form of -10? How it is calculated?
To convert -10 (decimal) to binary:
Repeatedly divide the absolute value (|-10| = 10) of the number by 2 until you get 0 in the quotient:
(10 / 2 = 5 R 0)
(5 / 2 = 2 R 1)
(2 / 2 = 1 R 0)
(1 / 2 = 0 R 1) // zero is the value in the quotient so we stop dividing
Place the remainders in order to obtain the binary equivalent:
1010
For an 8-bit cell the answer is 0000 1010, 16-bit cell 0000 0000 0000 1010, and so on.
Take the one's complement by inverting the bits (we will assume an 8-bit cell holds the final value):
0000 1010
1111 0101 // bits are inverted
Now take the 2's complement by adding 1:
1111 0101
+ 1
----------
1111 0110 // final answer
What happens with a 4-bit cell?
The one's complement would be:
1010
0101 // inverted bits
Taking the 2's complement produces:
0101
+ 1
----
0110 // final answer for a 4-bit cell
Since the number should be negative and the result does not indicate that (the number begins with 0 when it should begin with a 1) an overflow condition would occur.
Take the binary form of 10, invert all the bits, and add one.
10 0000 1010
invert 1111 0101
add 1 1111 0110
Follow this link. You can find the binary form of a negative number say -n by finding out the two's complement of n.
Your question has no "right" answer. First, you have to define the representation you want to use. Do you want to use two's complement, ones' complement, sign-magnitude, or something else? Then you have to define how many bits to use.
Let's say we are working with 5-bits wide representations.
+10: 0 1 0 1 0
Let's look at sign-magnitude system. In this system, the most significant bit (bit 5) is 1 if a number is negative, and 0 otherwise. The rest of the bits represent the magnitude (absolute value) of the number.
So we get:
-10: 1 1 0 1 0 (sign-magnitude, 5 bits)
Let's look at ones' complement now. Here, a negative number is represented by just changing 1s to 0s and vice-versa (hence the name ones' complement—you complement a number with respect to a long sequence of 1s).
So we get:
-10: 1 0 1 0 1 (ones' complement, 5 bits)
Finally, let's look at two's complement system. In this, we take a number in its ones' complement system, and then add 1 to it.
So we get:
-10: 1 0 1 0 1
1
---------
1 0 1 1 0 (two's complement, 5 bits)
---------
Thus, the binary representation of a negative number depends upon the system we use, and the number of bits available to us.
Also, you might have noticed the position of the apostrophe in ones' complement and two's complement. Why is is not one's complement or twos' complement? Then answer, from Knuth:
A two's complement number is complemented with respect to a single power of 2, while a ones' complement number is complemented with respect to a long sequence of 1s. Indeed, there is also a "twos' complement notation," which has radix 3 and complementation with respect to (2...22)3