Difference between revisions of "CSC103: DT's Notes 1"

From dftwiki3
Jump to: navigation, search
Line 79: Line 79:
 
At some point, applying this rule we reach 099.  Let's just apply our simple rule: the right most digit must roll over, so it becomes 0, and the digit to its left increments by 1.  Because this second digit is also 9 it, too, must roll over and become 0.  And because the 2nd digit rolls over, then the third digit, the one to the left of the 2nd digit increments by 1.  We get 100.  Does that make sense?  We are so good at doing this by heart without thinking of the process we use that sometimes it is confusing to deconstruct such knowledge.
 
At some point, applying this rule we reach 099.  Let's just apply our simple rule: the right most digit must roll over, so it becomes 0, and the digit to its left increments by 1.  Because this second digit is also 9 it, too, must roll over and become 0.  And because the 2nd digit rolls over, then the third digit, the one to the left of the 2nd digit increments by 1.  We get 100.  Does that make sense?  We are so good at doing this by heart without thinking of the process we use that sometimes it is confusing to deconstruct such knowledge.
  
 +
So let's remember this simple rule; it applies to counting in all number systems, whether they have 10 digits (like our decimal system) or some other number:
 +
 +
<tanbox>When counting, we always increment the right-most digit by 1.  When this digit must roll-over back to 0, we do so, and increment the digit to its left.  If this one rolls over to 0 as well, then we do so and increment the digit to its left, and so on.
 +
 +
Let's now count in ''base'' 2, in binary.  This time our "internal" table contains only 2 digits: 0, 1.
 
   
 
   
 +
00000
 +
 +
Good start!  That's zero.  It doesn't matter that we used 5 0s to write it.  Leading 0s do not change the value of numbers, in any base whatsoever.  We apply the rule: modify the right-most digit and increment it.  0 becomes 1.  No rolling over.
 +
 +
00001
 +
 +
Good again!  One more time: we increment the rightmost digit, but because we have reached the end of the available digits, we must roll over.  The right-most digit becomes 0, and we increment the 2nd digit from the right:
 +
 +
00010
 +
 +
Once more: increment the right-most digit:  this time it doesn't roll-over, and we do not modify anything else.
 +
 +
00011
 +
 +
One more time: increment the right-most digit: it rolls over and becomes 0.  We have to increment its neighbor to the left, which also rolls over and becomes 0, and forces us to increment its neighbor to the left, the middle digit, which becomes 1:
 +
 +
00100
 +
 +
 +
Let's pick up the pace:
 +
 +
00101
 +
00110
 +
00111
 +
01000
 +
...
 +
 +
And so on.  That's basically it for counting in binary.
 +
 +
Let's put the numbers we've generated in decimal and in binary next to each other:
 +
 +
decimal      binary
 +
000            00000
 +
001            00001
 +
002            00010
 +
003            00011
 +
004            00100
 +
005            00101
 +
006            00110
 +
007            00111
 +
008            01000
 +
009            01001
 +
010            01010
 +
...
 +
 +
 +
 +
 
The answers to these questions, and the ensuing solutions are provided by two giants of computer science, '''George Boole''', and '''Claude Shannon''' who worked at very different times.   
 
The answers to these questions, and the ensuing solutions are provided by two giants of computer science, '''George Boole''', and '''Claude Shannon''' who worked at very different times.   
  

Revision as of 23:41, 30 January 2012

--© D. Thiebaut 08:10, 30 January 2012 (EST)


This section is only visible to computers located at Smith College