I have this example:
If we take the binary representation of the decimal value 220 (1101 1100) and we wanted to extract the higher 4 bits, we could use a bitmask with the boolean AND operation:
1101 1100 (220)
AND 1111 0000 (240)
_________
1101 0000 (208)
I need to know how to get 240.
2**7 + 2**6 + 2**5 + 2**4 = 240
Where ** is exponentiation.
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).
Does anyone know how I can solve this problem? Any help would be great...... I cant seem to get my head around it.
As you know binary digits can only be either 1 or 0.
Say you had a 8 digit Binary number like a byte >>>>>> 0001 1000.
I'm trying to figure out an equation for the number of combinations you could get from an 8 digit binary number.
For example, if you had a two digit binary number, the binary combinations that you could have are:
00
01
10
11
Therefore the total combinations from a 2 digit binary number is 4.
Example 2
If you had a 3 digit number, the combinations would be:
000
001
010
100
101
111
110
011
Therefore the number of binary combinations from a 3 digit number is 8.
Example 3
If it were a 4 digit number, maximum binary combinations that you could have are either
0000
0001
0010
0100
1000
0111
0110
1111
1110
1101
1011
1001 Total maximum combination = 12
I Guess in a nutshell what im asking is .... if i had any number 6,7,15,8 or any number... how could i calculate the total maximum Binary combinations is there an equation to it ... I cant figure it out..ive tried for days now ;(
The number of numbers composed by d digits in base b is
b^d
n - number of digits
b - base
^ - power
b^n
So your base is 2 (binary), and u want to check combinations for 8 digit number
2^8 = 256
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.
I'm trying to understand these illustrations but there are parts which I don't understand:
"But the computer had to count backwards for the negative numbers"
Why does adding a 1 to the front of a binary mean the computer has to count backwards?
"Flip the bits and add 1!"
What does that mean add 1?
woops: http://csillustrated.berkeley.edu/PDFs/integer-representations.pdf
This may be easiest to show by example. Here are the numbers from -4 to 4 represented in binary:
4 0000 0100
3 0000 0011
2 0000 0010
1 0000 0001
0 0000 0000
-1 1111 1111
-2 1111 1110
-3 1111 1101
-4 1111 1100
So say we want to go from 1 to -1. We first flip all the bits of 1
1 0000 0001
flip bits
-----------
1111 1110
Then we add a 1:
1111 1110
+ 1
-----------
1111 1111
We now have -1.
I'm not seeing the illustrations, but you're probably talking about Two's complement representation. (http://en.wikipedia.org/wiki/Two's_complement)
Why does adding a 1 to the front mean the computer has to count backwards?
Due to how carrying works, FFFFFFFFF + 1 == 0
and 0 - 1 == FFFFFFFF. All the bits get flipped, including the first bit.
If you simply define the negative numbers as those starting with a 1 bit (80000000 - FFFFFFFF) then you get a nice uniform behavior for addition with a natural overflow.
Flip the bits and add 1: in 2's complement, this negates a number
~x+1 == -x; // always true
What you're talking about is called signed integers.