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
Related
I need to initialize an register with an specific decimal value in order to extract the bits of another register (by doing this). The only problem is, since I need to do an andoperation with a very large decimal, it turns out to be very difficult to convert a binary number into a decimal number without a calculator to perform this operation.
So I am interested to know if there is any way of initializing a register with a binary value directly
If your assembler/simulator does not allow you to write binary constants but it allows you to write hexadecimal ones then you may easily encode a binary number in hexadecimal.
Starting from the least significand bit, every 4 bits you encode its hexadecimal value using the following table:
0000 - 0
0001 - 1
0010 - 2
0011 - 3
0100 - 4
0101 - 5
0110 - 6
0111 - 7
1000 - 8
1001 - 9
1010 - A
1011 - B
1100 - C
1101 - D
1110 - E
1111 - F
If the original binary number does not have a multiple of 4 bits you fill the most significand bits to 0 until it fills the last packet.
For example, you may encode this words in hexadecimal converting them from binary numbers:
myvar: .word 0x1234 # binary 1 0010 0011 0100
other: .word 0xCAFEBABE # binary 1100 1010 1111 1110 1011 1010 1011 1110
I have n = 7. How many different values can be represented using 7 digits in In Hexadecimal Systems?
I approached it this way:
I set each bit of the 7 to be equal to 1. Therefore the highest number I get is 111 1111 = 16^0 + 16^1 + 16^2 + 16^3 + 16^4 + 16^5 + 16^6 which is equal to 17895697. I also consider zero being part of the answer, so my range is 0 to 17895697 and therefore, I get 17895698 different values. however, I know that in binary you would do 2^7 = 128. does it apply to hexadecimals as well? If I do it this way I get 16^7 = 268435456 which does not equal to what I got before.
Is any of my answers correct? if not, could someone please explain what it the right way to do this question?
It may be more simple explanation that you would expect, but it does not mean it would not work.
One hexadecimal digit can represent one of 16 values (0x0 to 0xF, or 0 to 15 if you prefer), so 16^7 = 268,435,456 and that's how many different values you can achieve if you use all the bits.
0000 0000 0000 0000 0000 0000 0000 to 1111 1111 1111 1111 1111 1111 1111.
The general formula is the sum of digit * base^place
Consider decimal numbers. What's the largest number you can represent with 3 decimal digits? The largest possible digit is 9. Therefore the max number is:
9*10^2 + 9*10^1 + 9*10^0 = 9*100 + 9*10 + 9*1 = 999
The next largest number would with be 1*10^3 = 1000
Another way to calculate the max of decimal three digits, is to get the smallest number with 4 digits and subtract 1.
The smallest decimal with 4 digits is 1000 or
1*10^3 + 0*10^2 + 0*10^1 + 0*10^0 = 1000
Now subtract 1
1000 - 1 = 999
The possible digits for a hex num are 0..F (values 0..15)
For a 7 digits the places range from 6 down to 0.
The largest possible number is therefore:
15*16^6 + 15*16^5 .... 15*16^0
Or the smallest number in hex with 8 digits is #10000000
1*16^7 + 0*16^6 ... + 0*16^0 = 1*16^7
So the largest possible number with in hex with 7 digits is
1*16^7 -1
16^7 is the correct answer. Why? Because for every character you add there are 16 times the previous possibilities. So for 7 characters it's 16^7.
Consider binary - 2^1, you get 0 and 1, 2 possible values. 2^2, you get 0 through 3 (00,01,10,11), 4 possible values.
Using hex, it's 16^7 possible values, which is 268,435,456 possible values.
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).
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.
Ok,so I know that the binary equivalent of 104 is 1101000.
10=1010
4=0100
so , 104=1101000 (how to get this??how these both mix together and get this binary?)
And from the example here...
the octets from "hellohello" are E8 32 9B FD 46 97 D9 EC 37.
This bit is inserted to the left which yields 1 + 1101000 = 11101000 ("E8").
I still understand this part , but how to convert 11101000 to E8?
I'm so sorry for all these noob questions , I just learn it yesterday , I googled and search for a whole day but still not really understand the concept...
Thank you.
Ok,so I know that the binary equivalent of 104 is 1101000.
10=1010
4=0100
You can't break apart a number like 104 into 10 and 4 when changing bases. You need to look at the number 104 in its entirety. Start with a table of bit positions and their decimal equivalents:
1 1
2 10
4 100
8 1000
16 10000
32 100000
64 1000000
128 10000000
Look up the largest decimal number that is still smaller than your input number: 104 -- it is 64. Write that down:
1000000
Subtract 64 from 104: 104-64=40. Repeat the table lookup with 40 (32 in this case), and write down the corresponding bit pattern below the first one -- aligning the lowest-bit on the furthest right:
1000000
100000
Repeat with 40-32=8:
1000000
100000
1000
Since there's nothing left over after the 8, you're finished here. Sum those three numbers:
1101000
That's the binary representation of 104.
To convert 1101000 into hexadecimal we can use a little trick, very similar to your attempt to use 10 and 4, to build the hex version from the binary version without much work -- look at groups of four bits at a time. This trick works because four bits of base 2 representation completely represent the range of options of base 16 representations:
Bin Dec Hex
0000 0 0
0001 1 1
0010 2 2
0011 3 3
0100 4 4
0101 5 5
0110 6 6
0111 7 7
1000 8 8
1001 9 9
1010 10 A
1011 11 B
1100 12 C
1101 13 D
1110 14 E
1111 15 F
The first group of four bits, (insert enough leading 0 to pad it to four
bits) 0110 is 6 decimal, 6 hex; the second group of four bits, 1000 is
8 decimal, 8 hexadecimal, so 0x68 is the hex representation of 104.
I think you are making some confusions:
104 decimal is 1101000 which is not formed by two groups splitting 104 into 10 and 4.
The exception is for hex numbers that can be formed by two groups 4 binary numbers (2^4 = 16).
So 111010000 = E8 translates into 1110 = E and 8 = 10000. 1110 (binary) would be 14 (decimal) and equivalent of E (hex).
Hex numbers go from 0 to 15 (decimal) where:
10 (decimal) = A (hex)
11(decimal) = B(hex)
...
15(decimal) = F(hex)
What you're missing here is the general formula for digital numbers.
104 = 1*10^2 + 0*10^1 + 4*10^0
Similarly,
0100b = 0*2^3 + 1*2^2 + 0*2^1 + 0*0^0
And for a hexidecimal number, the letters A-F stand for the numbers 10-15. So,
E8 = 14*16^1 + 8*16^0
As you go from right to left, each digit represents the coefficient of the next higher power of the base (also called the radix).
In programming, if you have an integer value (in the internal format of the computer, probably binary, but it isn't relevant), you can extract the right most digit with the modulus operation.
x = 104
x % 10 #yields 4, the "ones" place
And then you can get "all but" the rightmost digit with integer division (integer division discards the remainder which we no longer need).
x = x / 10 #yields 10
x % 10 #now yields 0, the "tens" place
x = x / 10 #yields 1
x % 10 #now yields 1, the "hundreds" place
So if you do modulus and integer division in a loop (stopping when x == 0), you can output a number in any base.
This is basic arithmetic. See binary numeral system & radix wikipedia entries.