Binary - Decimal - Hexadecimal
Revised June 27, 2018
Al: "I can't find the bug in this program!"
Sue: "Maybe a two got in there."
Al: "What?"
Sue: "Well it's all zeroes and ones, right?
Maybe a two got in there somehow."
... Years later, Al is still speechless ...
A Brief Note Regarding These Exercises: Most of these exercises can be solved quite easily with the Windows calculator (when operating in "scientific" mode), but you might want to have a feel for doing this stuff the "hard way" as well, because you won't have access to a calculator during Cisco exams (including those for CCNA, CCNP, CCDA, and CCDP).
00000001. Count from 0 to 255 in binary (use only two fingers!).
00000010. Convert the following binary numbers to decimal:
a. 1101 b. 1 c. 101 d. 110 e. 10110 f. 0010110 g. 1101111 h. 11101110111
00000011. Convert the following decimal numbers to binary:
a. 123 b. 242 c. 17 d. 247 e. 10001 f. 99 g. 214 h. 78
00000100. Is the binary number
010101010100101010101010101010101111101010000101011101011even or odd?
00000101. If it takes Al five (decimal) hours to run a marathon, how many minutes does it take him? Give your answer in binary.
00000110. Why can a computer with a 32-bit address bus access a maximum of 4 GB of memory? Some CPUs provide a 64-bit address space. How many memory locations will they be able to address individually? IP version 6 uses a 128-bit address space. How many addresses can it provide?
00000111. Convert the following IP addresses in "dotted-decimal" notation to their 32-bit binary equivalents:
a. 203.184.17.253 b. 255.255.0.0 c. 10.253.135.99 d. 124.36.0.226 e. 255.255.248.0 f. 80.90.100.110 g. 224.0.0.6 h. 255.255.255.252
00001000. Convert the following binary IP addresses to dotted-decimal:
a. 01101010 11010010 10101010 01011010 b. 00011110 10101010 01101001 01010101 c. 11111111 00000000 00000000 00000000 d. 11111001 00000000 00000000 11011101 e. 10000000000000010110011011111110 f. 11111111111111111111111000000000 g. 01001100011100001111000001111101 h. 10110011100011110000111110000010
00001001. Convert the following decimal numbers to eight-bit binary numbers:
a. 34 b. 62 c. 206 d. 19 e. 250 f. 72 g. 183 h. 66
00001010. Convert the following binary numbers to hexadecimal (base-16):
a. 0111 b. 1101 c. 1011011 d. 11101100 e. 100101101 f. 0101101011110000 g. 00000000000000000001 h. 11001010111001101011010011
00001011. Convert the following hexadecimal numbers to binary:
a. DEAD b. AF-05-12-57 c. 00-00-0C-9F-F2-A9 d. 00-00-5E-00-00-00 e. 123456789ABCDEF f. F0E1D2C3B4A59687 g. B0C h. 1000
00001100. Is the hexadecimal number:
AC93D9E02817C635A78B92C9F4837D2Aeven or odd?
00001101. Hex seems to be a hassle. Why do we use it?
00001110. A subnet mask is given as FF-FF-FC-00. What is its representation in dotted-decimal notation?
00001111. What are the hex and dotted-decimal representations for a "/29" subnet mask?
00010000. Convert the following hexadecimal numbers to decimal:
a. AA b. 123F c. FEDCBA d. D0-BE-D0 e. B8C f. FF-FF-FF-FA g. 10 h. BABE
00010001. Convert the following decimal numbers to hexadecimal:
a. 9 b. 32 c. 73 d. 255 e. 1,025 f. 4,099 g. 65536 h. 1,048,575
00010010. Convert the following binary numbers to decimal (these are pretty tricky!):
a. 0.1 b. 1.11 c. 101.01101 d. 100101.11101 e. 11101111.10000001
00010011. Convert the following decimal numbers to binary (these are really tricky!):
a. 0.5 b. 1.0625 c. 7.7500 d. 163.2 e. 3.141592654
00000001. Count from 0 to 255 in binary (you can't do it with only two fingers, but it's good practice!).
Remember that in binary (base-two), just like in decimal (base-ten), each position you move to the left increases in value by the amount of the base. In decimal, for example, the positions are valued "ones", "tens", "hundreds", "thousands" and so on, and as we move left, each position increases by the value of the base, which in this case is ten. In binary, the positions are valued "ones", "twos", "fours", "eights" and so on, each time increasing by the amount of the base, which in this case is two. Those of us who are familiar with a scheme called "scientific notation" may recall that the right-most position represents the base to the zero power, and then, as we move left, each position increments the exponent (power) by one, such as "two-to-the-zero" (which is one), "two-to-the-first" (two), "two-to-the-second" (four), etc. It works that way for all bases, not just ten and two. Here are the binary representations of the numbers from zero to 255:
0-31 32-63 64-95 96-127 128-159 160-191 192-223 224-255 00000000 00100000 01000000 01100000 10000000 10100000 11000000 11100000 00000001 00100001 01000001 01100001 10000001 10100001 11000001 11100001 00000010 00100010 01000010 01100010 10000010 10100010 11000010 11100010 00000011 00100011 01000011 01100011 10000011 10100011 11000011 11100011 00000100 00100100 01000100 01100100 10000100 10100100 11000100 11100100 00000101 00100101 01000101 01100101 10000101 10100101 11000101 11100101 00000110 00100110 01000110 01100110 10000110 10100110 11000110 11100110 00000111 00100111 01000111 01100111 10000111 10100111 11000111 11100111 00001000 00101000 01001000 01101000 10001000 10101000 11001000 11101000 00001001 00101001 01001001 01101001 10001001 10101001 11001001 11101001 00001010 00101010 01001010 01101010 10001010 10101010 11001010 11101010 00001011 00101011 01001011 01101011 10001011 10101011 11001011 11101011 00001100 00101100 01001100 01101100 10001100 10101100 11001100 11101100 00001101 00101101 01001101 01101101 10001101 10101101 11001101 11101101 00001110 00101110 01001110 01101110 10001110 10101110 11001110 11101110 00001111 00101111 01001111 01101111 10001111 10101111 11001111 11101111 00010000 00110000 01010000 01110000 10010000 10110000 11010000 11110000 00010001 00110001 01010001 01110001 10010001 10110001 11010001 11110001 00010010 00110010 01010010 01110010 10010010 10110010 11010010 11110010 00010011 00110011 01010011 01110011 10010011 10110011 11010010 11110011 00010100 00110100 01010100 01110100 10010100 10110100 11010011 11110100 00010101 00110101 01010101 01110101 10010101 10110101 11010100 11110101 00010110 00110110 01010110 01110110 10010110 10110110 11010101 11110110 00010111 00110111 01010111 01110111 10010111 10110111 11010110 11110111 00011000 00111000 01011000 01111000 10011000 10111000 11010111 11111000 00011001 00111001 01011001 01111001 10011001 10111001 11011000 11111001 00011010 00111010 01011010 01111010 10011010 10111010 11011001 11111010 00011011 00111011 01011011 01111011 10011011 10111011 11011010 11111011 00011100 00111100 01011100 01111100 10011100 10111100 11011011 11111100 00011101 00111101 01011101 01111101 10011101 10111101 11011100 11111101 00011110 00111110 01011110 01111110 10011110 10111110 11011101 11111110 00011111 00111111 01011111 01111111 10011111 10111111 11011111 11111111
00000010. To convert from binary to decimal, just multiply each bit by the value of its position, and add the results for all positions. The right-most position is worth one. When dealing with binary numbers, the value of each position increases by a factor of two as we move left, so the next position to the left is worth two, the next position is worth four, the next is worth eight, etc. Again, for fans of scientific notation, the base is two, and the exponents start at zero for the right-most position, and increment by one for each position as we move left. That is, in an eight-bit binary number, the columns (bits) are worth:
1 2 6 3 1 8 4 2 6 8 4 2 1 ---------------------- 1 1 1 1 1 1 1 1 = 255 (128 + 64 + 32 + 16 + 8 + 4 + 2 + 1)Therefore, converting the binary number 01101 to decimal (starting from the left and moving to the right) gives [0 x 16] + [1 x 8] + [1 x 4] + [0 x 2] + [1 x 1], or 13. You can start at the right and move left if you find that more convenient, just make sure you do the math correctly.
a. 13 b. 1 c. 5 d. 6 e. 22 f. 22 g. 111 h. 1,911
00000011. Going from decimal to binary is easy. Just use this algorithm:
Divide the decimal number (which mathematicians would call the "dividend") by 2 (the "divisor"). Write down the result (the "quotient") and what is left over (the "remainder"). Using the quotient as the new dividend, repeat until the dividend is zero. Now, read the remainders in reverse order, and you have the binary equivalent of the original decimal number.
For example, suppose we want to convert the decimal number 123 to binary. First, do the divisions (stop when the quotient reaches zero):
123 / 2 -> Q = 61, R = 1 61 / 2 -> Q = 30, R = 1 30 / 2 -> Q = 15, R = 0 15 / 2 -> Q = 7, R = 1 7 / 2 -> Q = 3, R = 1 3 / 2 -> Q = 1, R = 1 1 / 2 -> Q = 0, R = 1Now read the remainders from bottom to top:
123 / 2 -> Q = 61, R = 1 ^ top! 61 / 2 -> Q = 30, R = 1 | to 30 / 2 -> Q = 15, R = 0 | bottom 15 / 2 -> Q = 7, R = 1 | from 7 / 2 -> Q = 3, R = 1 | bits 3 / 2 -> Q = 1, R = 1 | the 1 / 2 -> Q = 0, R = 1 | ReadThe binary equivalent of decimal 123 is 1111011. We can (and should!) check our work by using the method from the previous problem, which (working from left to right) gives [1 x 64] + [1 x 32] + [1 x 16] + [1 x 8] + [0 x 4] + [1 x 2] + [1 x 1], or 123. If we want to represent the answer as an eight-bit binary number, just add a zero on the left (referred to as "zero-padding") for 01111011.
a. 1111011 b. 11110010 c. 10001 d. 11110111 e. 10011100010001 f. 1100011 g. 11010110 h. 1001110Note that there are sometimes ways to "cheat". For example in "a" above (Convert 123 to binary"), since 1111111 in binary is 127 in decimal, if we turn off the 4's bit (0000100) in 127 (1111111), we get 123 (1111011). Likewise, in "d", since 255 is 11111111, 247 is 11110111 (eight less). With a little practice, you can exploit this to good effect in more complicated problems.
00000100. Odd, because it ends in a "1".
00000101. First convert five (decimal) hours into 300 (decimal) minutes. Then convert 300 (decimal) minutes into binary. The answer is 100101100 (binary) minutes.
00000110. A computer with a 32-bit address bus is said to have a "32-bit address space". Since with 32 bits you can have 4,294,967,296 unique combinations:
00000000000000000000000000000000 (0) 00000000000000000000000000000001 (1) 00000000000000000000000000000010 ... and so on, and so forth ... 11111111111111111111111111111101 (4,294,967,293) 11111111111111111111111111111110 (4,294,967,294) 11111111111111111111111111111111 (4,294,967,295)such a machine could store and retrieve information from 4,294,967,296 memory locations (if you don't believe there are 4,294,967,296 unique combinations, you are welcome to list and count them!). The bottom line is that the number of possible combinations of bits on the address bus is the number of memory addresses that the computer can address individually. Machines with a 64-bit address space can individually address 18,446,744,073,709,551,616 memory locations (nobody can afford that many!). Likewise, the 128-bit address space of IPv6 will allow for 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses. That should last a while! Note that in order to find the answers for the 64-bit and 128-bit address spaces, I wrote a special program that will handle precise calculations involving huge integers (whole numbers). No "normal" calculator (not even a fancy scientific) will handle numbers that large with the number of significant digits I quoted.
00000111.
a. If we convert each decimal value to a binary octet, we have:
203 184 17 253
11001011 10111000 00010001 11111101
b. 11111111 11111111 00000000 00000000
c. 00001010 11111101 10000111 01100011
d. 01111100 00100100 00000000 11100010
e. 11111111 11111111 11111000 00000000
f. 01010000 01011010 01100100 01101110
g. 11100000 00000000 00000000 00000110
h. 11111111 11111111 11111111 11111100
00001000.
a. 106.210.170.90 b. 30.170.105.85 c. 255.0.0.0 d. 249.0.0.221 e. 128.1.102.254 f. 255.255.254.0 g. 76.112.240.125 h. 179.143.15.130
00001001.
a. 00100010 b. 00111110 c. 11001110 d. 00010011 e. 11111010 f. 01001000 g. 10110111 h. 01000010
00001010. To convert a binary number to its hex representation, first group the bits into "nibbles" (a "nibble" is four bits, or half a byte), starting from the right. For example, given the binary number 10110110011, the right-most nibble is 0011. The next nibble to the left is 1011. The left-most nibble is 0101 (note the addition of a leading zero to get four bits). Now, convert each nibble to its hex equivalent, using the following table:
Binary Hex 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 FUsing the nibbles 0101 1011 0011, we obtain the values 5 B 3. Finally, concatenate (smash together) the hex digits in a suitable manner, such as 0x5B3, or whatever representation is handy. Long hex numbers are typically represented as pairs of hex digits separated by dashes (e.g., 05-B3). This is done because a pair of hex digits represents two four-bit nibbles, which is one eight-bit byte.
a. 0x7 b. 0xD c. 0x5B d. 0xEC e. 0x012D f. 0x5AF0 g. 0x1 h. 0x032B9AD3 (or 03-2B-9A-D3)
00001011. To go from hex to binary, just reverse the process from above. Using the table, convert each hex digit into its binary (nibble) equivalent, and then concatenate the nibbles. For example, to convert the hex value A2F to binary, convert the hex digits A, 2 and F to binary, which gives 1010 0010 1111, and smack them together (in order) to get 101000101111.
a. 1101111010101101 b. 10101111000001010001001001010111 c. 000000000000000000001100100111111111001010101001 d. 000000000000000001011110000000000000000000000000 e. 000100100011010001010110011110001001101010111100110111101111 f. 1111000011100001110100101100001110110100101001011001011010000111 g. 101100001100 h. 1000000000000
00001100. Recall that in hexadecimal (base-sixteen), there are sixteen digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E and F (where A, B, C, D, E and F represent 10, 11, 12, 13, 14 and 15 in decimal, respectively). Therefore, the answer is "even", because it ends in an "A", which is ten in decimal (an even number).
00001101. Because each hex digit is worth four binary bits, we can use hex as shorthand for binary numbers. For example, an IP version 6 address is represented as a 32-digit hex number. Assuming that we still have to manipulate IP addresses in the future, would you rather type or write 32 hex digits, or its equivalent as 128 binary digits?
00001110. First, expand each hex digit into its binary nibble equivalent:
F F F F F C 0 0
1111 1111 1111 1111 1111 1100 0000 0000
Now, make an octet out of each nibble pair:
11111111 11111111 11111100 00000000Convert each octet to its decimal equivalent:
11111111 11111111 11111100 00000000
255 255 252 0
Separate the values by periods to get 255.255.252.0
00001111. A "/29" subnet mask means 29 ones, followed by 3 zeroes (subnet masks are always 32 bits in length). Thus, its binary representation is:
11111111111111111111111111111000To convert to hex, group the bits by nibbles:
1111 1111 1111 1111 1111 1111 1111 1000And convert each nibble to a hex digit:
1111 1111 1111 1111 1111 1111 1111 1000
F F F F F F F 8
To get the hex representation, group the hex digits in "paired-dashed" format:
FF-FF-FF-F8To convert the mask to dotted-decimal format, divide the binary format into octets:
11111111 11111111 11111111 11111000Convert each octet to its decimal equivalent:
11111111 11111111 11111111 11111000
255 255 255 248
Separate the values with periods to get 255.255.255.248
00010000. Going from hex to decimal is similar to going from binary to decimal. Just convert each hex digit to its decimal equivalent, multiply by the value of its position, and add the results for all positions. As with binary and decimal, the right-most position is worth one. When dealing with hex numbers, the value of each position increases by a factor of sixteen as we move left, so the next position to the left is worth sixteen, the next position is worth 256 (decimal), the next is worth 4,096, etc. Again, for fans of scientific notation, the base is sixteen, and the exponents start at zero for the right-most position, and increment by one for each position as we move left. Therefore, converting the hex number 2AB to decimal (starting from the right and moving leftwards) gives [11 x 1] + [10 x 16] + [2 x 256], or 683. As with binary, you can start at the left and move to the right, just make sure that you don't scramble the values while multiplying and adding positions.
a. 170 b. 4,671 c. 16,702,650 d. 13,680,336 e. 2,956 f. 4,294,967,290 g. 16 h. 47,806
00010001. As with decimal to binary, going from decimal to hex is a little tricky. You have to figure out how many hex digits you need, and the value of each. Let's do an example ...
Suppose we want to convert the decimal number 11,267 to hex. How many hex digits are necessary? Well, since the hex positions start at the right with a value of one, and the value increases by a factor of sixteen each time we move one position to the left, they follow the right-to-left progression of 1-16-256-4,096-65,536-etc. Since our value 11,267 is smaller than 65,536, we don't need to go that far. We only need the 1-through-4096 positions, or four hex digits, and we can therefore represent our decimal number of 11,267 with a four digit hex number. To find the hex number, we start with our decimal number of 11,267, and with our highest-valued hex position of 4,096. How many times does 4,096 go into 11,267? Twice, with 3075 left over. Therefore, our first hex digit is "2", and the hex result so far looks like "2". Now we repeat the process. How many times does 256 go into 3,075? Twelve (which is "C" in hex), with 3 left over, so "C" is our next hex digit, and the hex result so far is "2C". How many times does 16 go into 3? Zero, so that's our next hex digit, and that gives us "2C0". How many times does one (the last position) go into 3? Three, so that's our next (and final) hex digit, and the hex result is "2C03". Again, while this looks long and involved, it is really quite quick once you get the hang of it.
Another way to do it is to first convert the decimal number to binary (using whatever method you prefer), and then convert the resulting binary to hex (which is easy, just do one nibble at a time). Either way, we can check our work by using the method from the previous problem, which (working from right to left) gives [3 x 1] + [0 x 16] + [12 x 256] + [2 x 4096], or 11,267.
a. 0x9 b. 0x20 c. 0x49 d. 0xFF e. 0x401 f. 0x1003 g. 0x10000 h. 0xFFFFF
00010010. A new twist: the "binary point"! It's like a decimal point, but it is used with binary numbers. It works just like the decimal point, except that the values to the right of the binary-point are divided by two as you move farther right, instead of by ten as with a decimal point. That is, the position immediately to the right of the binary point is worth one-half, the next position further to the right is worth one-fourth, then one-eighth, one-sixteenth, etc (whereas with a decimal point it goes one-tenth, one-hundreth, one-thousandth, etc). As usual, when converting from binary to decimal, just determine the values of the columns with ones, and add them up to get the decimal result, and ignore the zero bits.
a. 0.5 b. 1.75 c. 5.40625 d. 37.90625 e. 239.50390625
00010011. Decimal to binary can be tricky when fractions are involved. As with decimal numbers, there are some fractions (such as one-third, which is 0.3333333...continuing forever) that cannot be represented with a finite number of binary digits. In other words, the part to the right of the binary-point goes on forever. Also, just because you can represent a number "nicely" as a decimal doesn't mean you can represent it nicely as a binary, and vice versa.
a. 0.1 b. 1.0001 c. 111.11 d. 10100011.00110011 etc ... goes on for many (maybe infinitely many) digits e. 11.00100100 etc ... goes on for infinitely many digits