Binary - Decimal - Hexadecimal

Revised February 7, 2005

Maybe a two got in there!

Questions? Comments? E-mail: AL "at" CatSpace "dot" com


       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).


EXERCISES (numbered in binary, of course!):

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

  010101010100101010101010101010101111101010000101011101011
even 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:

  AC93D9E02817C635A78B92C9F4837D2A
even 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?


EXTRA CREDIT (Not on the Cisco tests - for math geeks only!):

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


ANSWERS:

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 = 1
Now 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 | Read
The 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. 1001110
Note 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   F
Using 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 00000000
Convert 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:

  11111111111111111111111111111000
To convert to hex, group the bits by nibbles:
  1111 1111 1111 1111 1111 1111 1111 1000
And 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-F8
To convert the mask to dotted-decimal format, divide the binary format into octets:
  11111111 11111111 11111111 11111000
Convert 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


EXTRA CREDIT ANSWERS:

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


Return to the top of this Exercise!

Return to the directory of Goodies!


Copyright © 2005 Alchemy, Inc. All rights reserved.