Jared Kipe Software Blog

Your First C Program

Sat, 10 Dec 2011 14:19:49 -0800

Practically, all modern languages descend from C, and thus use most of C's principles and basic structures. C is a perfect place to start learning about basic programming. C can be a launching platform for both more advanced C (like embedded operating systems), or, more likely, object oriented languages like C++ and Objective-C.

I'm not going to lie, this code isn't going to be exciting. But let's dissect the standard "Hello World" program in C.

#include <stdio.h>
int main(int argc, const char *argv[]) {
	printf("Hello World!");
	return 0;
}

Functions

There is a very popular metaphor that a function is like a toaster. A toaster is any device where you put in bread, push a button or lever, and at a pre-determined time, "toast" comes out. Functions work similarly. Sometimes you design, or make the function yourself, sometimes the function already exists (like the toaster) and you simply use it. Either way, the function needs to follow very specific rules on how you can use or "call" a function, what the various parameters or "arguments" of the function are and what the function gives back when it is done.

Lets concern ourself with a toaster that takes a single piece of bread. In C, this function (or toaster) would be prototyped like this:


toast toaster(bread slice, int time);

The first word is toast, this is the "return type" or what is given back to the user or "caller" when the function is done. toaster is the name of the function. "bread slice" is the type of the first argument (bread) and slice is the local variable name for that argument. "int time" is the type of the second argument (integer) and time is the local variable name for the second argument.

You don't really need to know the mechanism by which toaster makes the bread into toast, or how the time affects it. In fact you don't even need to include the word "slice" and "time" in the prototype, but their names are usually hints to the caller on what the arguments actually are.

The program itself is effectively a function named main(). Every program needs a main() function, which is the function that is run when the program itself executes. It needs to be named main, and for right now you shouldn't really concern yourself with the arguments or return type of main.

The C Preprocessor

The C preprocessor gets run on your files before compilation, and usually results in a fancy "search and replace" getting called on your document. There are a handful of preprocessor directives, and I will go over them each time I use them. All of these directives begin with the # symbol, usually near the start of a document and needs to be on its own line. Preprocessor directives do not end with a semicolon, as they are not actual C instructions and always get stripped out of the file before compilation. The preprocessor also strips out comments, anything after a double forward slash (//) or between the multiline comment block (/* blah blah */).

New C Preprocessor directives:

#include

#include effectively takes a single argument that is the name of a file, or path with file name, that is to be included in-line in the document right where the #include was. These are almost always header files (xxxx.h) that include things like function prototypes and struct declarations that are used in the current file (xxxx.c). Without the prototype of a function, the compiler may not be able to infer the correct information about the function when you call it in your own source code.

#include's can have the file name surrounded by less than/greater than symbols, this indicates it is a system header that you did not write and the preprocessor will look in special include folders to find it. If the file name is surrounded with double quotes the preprocessor will look in the same folder as the current file, use this when including your own header files in your source.

Examples:

// system header stdio.h
#include <stdio.h>
// personal header, probably in the same directory as the current file
#include "myFile.h"

New C Functions:

int printf(const char *format, ...);

declared in <stdio.h>

printf() is used to print to standard out (usually the console), format is a constant string that can include 0 or many special format arguments. The ... indicates that it can take a variable number of arguments, there will be 0 or many arguments to match the special format arguments in the format string. The integer return value is the number of special format arguments printf() matched.

The most common way of using printf() is to output an integer or double you have performed a calculation on. There are a number of format specifiers to achieve a wide array of output, click the function prototype to learn more.

Examples:

#include <stdio.h>
int i = 5 + 4;
printf("5 + 4 = %d", i);
/* %d is a signed integer, outputs...
5 + 4 = 9
*/

Understanding Binary: Negative Numbers

Tue, 01 Nov 2011 19:27:15 -0700

Building on the previous article on Method of Complements, lets take a look at the difference between signed and unsigned integer types.

In the article on Primitive Data Types I mentioned that integers come in signed and unsigned flavors. Lets say we are working on 8-bit char's, the unsigned version will use all 8 bits for counting from 0 to 255, while the signed version will use 7 bits to count from 0 to 127, and the last bit to basically toggle that range to negative. (in actuality its from -128 to 127 as we will see soon)

Instead of simply toggling the last bit to make a positive number negative, computers use 2's complement.

1's Complement

Before we move on to 2's Compelement, we should learn 1's Complement. This is equivilant to learning 9's Complement before learning 10's Complement from the earlier post.

1's Complement is effectively the opposite of whatever the current bit holds, repeated for every bit.

In C (and similar languages) there is a handy operator to take any primitive type and compute the 1's complement. That is the Bitwise NOT operator: ~

~1101b = 0010b
~0111b = 1000b

Very easy stuff.

2's Complement

The rule for getting 2's Complement from 1's Complement, is the same for getting 10's Complement from 9's Complement in base 10 numbers. That is, 2's Complement is 1's Complement plus one. The same tricks apply as well, namely that all all rightmost 0's can stay 0, and simply add 1 to the first rightmost non-zero bit. (in practice the first rightmost 1 just stays 1 and you flip all the bits left of it)

In C (and similar languages) there is a handy operator to turn an integer type into the 2's complement (and is the subject of the article). That is the Unary Minus operator: -

-1101b = 0011b
-0111b = 1001b
-1100b = 0100b

Subtraction Using 2's Complement

Lets do a quick binary subtraction problem using 8-bit signed integers, 100-37 in decimal.

0110 0100b
-0010 0101

2's complement makes it:

0110 0100b
+1101 1011b
0011 1111

Our final answer, 63 in base 10.

Now if you've been following along you may be wondering, why isn't the answer 0001 0011 1111b ?? Well in the Method of Complements, you need to do two things to get the correct answer.

1: Pad extra 0's in the higher order bits that may not be there (like 100-37 becomes 100-037) before you do the complementing.

2: Throw away the extra digit that is higher order than either of the starting numbers.

The beauty of working in fixed bit integer numbers, like in a computer, is that both of these rules are automatically followed. Every number has exactly 8-bits, so you don't need to pad. And the 'extra' 9'th bit doesn't fit in the memory space, and thus just dissapears.

Beyond Subtraction

Storing negative numbers in their Complement versions has another advantage. Namely that addition and subtraction can become agnostic as to the sign of the operands. If you can add numbers, then adding a negative number is the exact same procedure. And subtraction is to just find the complement of the second number and then use what you have for addition. And by agnostic as to the sign, I mean that you don't need to worry about special cases like when you subtract using a negative number.

4 - (-3) = 4 + (-(-3) = 7

4 = 0100b
3 = 0011b
-3 = 1101b
--3 = 0011b
0100b + 0011b = 0111b (which is 7 by the way)

Method of Complements

Tue, 25 Oct 2011 10:22:31 -0700

or subtraction using addition

Most people would agree that subtraction is more difficult, time consuming, and error prone than addition.

There is a way to complete a long subtraction problem using addition and the complement of the subtrahend (the number being subtracted).

9's Complement

9's complement is simply the number you would need to add to digit x to make that digit 9. For numbers using more than 1 digit, you apply the complement to each digit.

8722 => 1277
9215 => 0784

Subtraction using 9's Complement

As you might have guessed, subtraction involves the addition of this 9's complement.

9111
- 8722

9111
+1277
10388

This can't be right, this is in fact bigger than the original numbers. Well there are two more simple rules to apply this algorithm correctly. Drop the left most digit completely, and add 1 to the answer.

0389 is in fact the correct answer. (I left the preceding 0 in place just to remind you what the left most digit was.)

This problem is a best case scenario as we replaced a subtraction problem that would have 3 'borrows' with an addition problem with 0 'carries'.

10's Complement

That business about adding the 1 at the end can, and should, be rolled into the complement itself, and leads to some simplification of the rules for finding the complement. You can leave all the rightmost zeroes zero, and just add 1 to the rightmost non-zero digit after finding the 9's complement.

259000 =(via 9's)> 741999

See if you add 1 to that, all the 9's become 0's again.

259000 =(via 10's)> 742000

What about the "drop the leftmost 1 (digit)" part?

That part is central to the Method of Complements, and is part of what makes it so great when using fixed number of digits to do calculations (remember the bit lengths of the integer numbers in the Primitive Data Types?) The minuend and subtrahend need to have the same number of digits, thus any difference needs to be padded with extra 0's before finding the complement.

920-70 => 920-070 => 920+930 = 850

Here we did fixed-3-digit addition/subtraction where the extra thousands place digit overflows or dissapears.

In my next entry I will expand on this, specifically for digital computers.

Steve Jobs: Innovator, Visionary, Inspiration.

Wed, 05 Oct 2011 22:29:10 -0700

Today marks the passing of one of, if not the, most important visionaries of the computer age.

Those first colored series iMacs turned Apple around from certain death. The iPod created a new word, and a new industry. Mac OSX revolutionized the way we interact with our computers, and how they interact with the world. The iPhone might as well be magic, it certainly is to me.

There is not a single segment of the digital world that has not felt the touch of this innovator. And he has been a constant source of inspiration personally.

Steve Jobs, you will be missed.

New VPS (massive outage)

Sat, 30 Jul 2011 20:36:58 -0700

Just got everything setup after my oh 60 hours or so of downtime. Why the downtime? ...

Oh, just ClubUptime.com going out of business with no warning, and a very poor explanation.

Somehow I managed to luck out and have taken a SQL dump from my sites LITTERALLY the day before the servers got disconnected. There were a few not so lucky customers. You can find more over on ClubUptime's facebook wall... presumably for a limited time only!

EDIT: Looks like they got some backups up for not so fortunate customers. Good luck everyone!

Maximum Width Text

Sat, 16 Jul 2011 10:51:32 -0700

Ever come across an element where you wished that an automatically wrapping element, like an h1, would automatically change its font-size property to accommodate a certain width? I've got some CSS and Javascript for you.

Why?

Sometimes you have elements on your website that really should have fixed widths, maybe they need to fill a side bar, and you have problems with text that you either can't control or don't want to control too carefully. Maybe it displays content entered by a home user, maybe it was working great until you got a title that was just slightly longer than another title and suddenly you wrapped to a new line.

Finished Examples:

Short Title

Lorem paragraph

Long Title without any Javascript

Lorem paragraph

Long Title with our new Javascript

Lorem paragraph

How?

Here is the HTML for the second and third examples. The structure is the only real important parts. The id="FixedWidthText", is only important for the Javascript, and only for this specific example. (where we don't want all the blocks to have fixed widths)

<div class="block">
	<div class="blockTop">
		<h3 class="blockh3">Long Title without any Javascript</h3>
	</div>
	<p>Lorem paragraph</p>
</div>
 
<div class="block">
	<div class="blockTop">
		<h3 id="FixedWidthText" class="blockh3">Long Title with our new Javascript</h3>
	<p>Lorem paragraph</p>
</div>

CSS

Firstly we need some CSS to define the size of the block. (as well as style them to show off the individual boxes better) The class ".blockTop" is important for visualizing the part around the h3 that we will be changing the size of implicitly. ".blockTop" could be an image or maybe have rounded corners.


.block {
	width: 300px;
	background: #eee;
	border: 1px solid #aaa;
	margin-bottom: 20px;
}

.blockTop {
	width: 100%;
	background: #7ab1d8;
}

.block h3.blockh3{
	display: inline-block;
	color: #666;
	font-size: 25px;
	padding-left: 5px;
	line-height: 35px;
	margin: 0;
	*display: inline;
}

Important parts of this CSS:

To be able to fix the width of an element, you need to be able to measure the width of it. This is a problem for the normally block displayed H's (H1, H2 ...) as they have a tendency to be as wide as their surrounding parent element (in this case 300px).

To solve this we change it to display as an inline-block. Display inline is not good enough, because then the width is only as wide as where the line break is, thus inline would look exactly like the non shrunken example.

The padding-left is only to indent it a little from the left side so that the text isn't right up against the border (like the paragraphs under them), and we didn't use a padding-right because we will be fixing the width anyway so there is no reason to make sure it doesn't touch the right border.

The line-height is somewhat important because I want the text to be centered vertically in the blue part (the containing .blockTop). (note that the shrunken blue block is the same size and the first example's despite the much larger font)

Javascript

Without any Javascript example block 2 and 3 would look effectively identical. The key to shrink them is to basically use Javascript to measure the width of the block and if it is beyond a certain width, shrink the "font-size" incrementally until it fits.

jQuery.noConflict();
jQuery(window).load(function() {
	jQuery('#FixedWidthText').textMaxWidth(290, 10);
});

// assumes maxWidth in px, and font-size in px
jQuery.fn.textMaxWidth = function(maxWidth, minFontSize) {
	this.each(function(){
		var width = jQuery(this).width();
		var fontSize = minFontSize + 1;
	
		while (width > maxWidth && fontSize > minFontSize) {
			fontSize = parseInt(jQuery(this).css('font-size'));
			fontSize -= 1;
			jQuery(this).css('font-size', fontSize + 'px');
			width = jQuery(this).width();
		}
	});
}

I'm obviously using the jQuery library to achieve the desired results. I'm also extending jQuery to add the textMaxWidth() method in such a way that it doesn't matter if we called it on jQuery('#FixedWidthText') or jQuery('.blockh3'), the latter would be what we would use if this wasn't a very specific example.

minFontSize is optional, but a pretty good idea. Without it, if you tried to shrink an element that, for some reason, doesn't change its width while the font-size shrinks, you don't end up with an infinite loop.

The most important argument is maxWidth. This should be smaller than the physical maximum width, in our case 300px, because when the text wraps around to the new line it will effectively be the width of the containing element minus any paddings or margins you assigned. In our case 300px - 5px padding-left - 5px imaginary padding-right = 290px.

Compatibility?

I've tested this to work as intended in IE8+, Safari, Firefox, Opera, and Chrome. IE6&7 don't support display: inline-block properly and fail gracefully to the multiple line display: inline.

Download the Source Code:

Max Width Text CSS
Max Width Text Javascript

Primitive Data Types

Wed, 29 Jun 2011 09:02:13 -0700

The Primitive Data Types are data types that are used in every day in programming and usually correspond to the most basic building blocks of all the other Objects or data types you will be programming with down the road.

The primitive data types come in a few flavors, and usually have a couple of sizes for each as well. The sizes of the types depend on the language used, the specific compiler, and thus the computer architecture you are programming in (i386, x86_64 ...)

Integer Types

Integer types are basically just counting numbers. If you want to keep track of how many cows you have, the integer type is the one you will probably want to use.

In strongly typed languages like C or Java, you define these numbers with the data type name in front of the variable name, e.g. "int x = 5;"

In both strongly typed languages and weakly typed languages (like PHP and Javascript) you can force one type into the integer type by what we call "casting", e.g. "$x = (int)$_GET['x'];"

name:	size:
char	8-bit
short	16-bit
int	32-bit
long long	64-bit

They also come in "signed" and "unsigned" flavors. Signed versions can keep track of negative numbers but do so by dedicating their last (highest order) bit to keep track of the sign. Unsigned types use all of the bits for counting, thus they can count higher.

Languages like C# and Java actually have other names for these differently sized integer types. You can checkout the giant table of integer types over on wikipedia.

Floating Point Types

Floating point types are for real numbers like 1.2 or 3.14, that is numbers that are not whole numbers.

Floating point types are basically like always representing numbers in scientific notation say 1.22311 x 10^3. They break some of their bits up to represent the exponent and the significant digits, and a single bit for the sign.

Floating point numbers do NOT accurately represent all numbers, and this causes confusion and frustration when you try to use them where perfect base 10 accuracy is needed. (like banking) This failure is the equivilant to say 1/3 represented as a base 10 decimal number. The more accurately you want to define 1/3 as a base 10 decimal you need more and more digits 0.3333333... 1/10 (0.1) is for example not representable perfectly as a floating point number.

Another problem with Floating Point types is that the bigger/longer the number gets, the less accurate it gets. Rather, floating point numbers have a fixed number of significant digits, once you use those up, the remaining ones will be inaccurate.

There are really only two major size flavors for floating point types.

float 16-bits (on 32-bit processors) 32-bits (on 64-bit processors)

double 32-bits (on 32-bit processors) 64-bits (on 64-bit processors)

I personally always use doubles if I care about the accuracy even a little bit. Here is a more detailed analysis on the internals of floating point types.

Char

You may have though wondered what was up with the name for the smallest integer data type. Well it is certainly an integer type mathematically and structurally, but it has another important usage in several languages.

Char is used to store a single alpha-numeric character (and quite a few non alpha-numeric characters like ?!%$#_)

Basically characters like 'A' or 'p' have integer equivalents, 65 and 112, as defined by various character encoding schemes. E.g. ASCII, and utf-8.

Enum

Enum stands for enumerated type, and is essentially a way for you to define keywords to specific integer values. Examples would be days in a week, or suits of playing cards.

Enum's come up in C and its descendants such as C++ and Java, as well as databases such as MySQL.

enum suit { HEART, DIAMOND, SPADE, CLUB };

Understanding Binary: Hexadecimal

Tue, 28 Jun 2011 18:48:52 -0700

Topically, hexadecimal is extremely useful for programmers to understand, and makes binary in general quite a bit easier to work with and represent both in code and out.

The Hexadecimal System (base 16)

Binary numbers range from 0 to 1, decimal numbers range from 0-9, and hexadecimal numbers range from 0-15. To keep it relatively easy to read, and more succinct than writing 10, 11, 12... out the numbers over 9 are remapped to the characters A, B, C...

This allows a single "digit" to be represented by a single "character" in writing.

base 10	base 16	base 10	base 16
0	0	8	8
1	1	9	9
2	2	10	A
3	3	11	B
4	4	12	C
5	5	13	D
6	6	14	E
7	7	15	F

It is customary to write hexadecimal numbers as 0x(hexadecimal), e.g. 0xF9, or 0x23A2.

Justification for Hexadecimal

Now that you know what a hexadecimal number is, and how to recognize them... Why would we bother with a completely new numbering scheme?

Remember how ugly it became working with relatively large binary numbers, say over 100 (7 binary digits)? Remember when I said it was customary to keep long binary numbers clumped up into 4 digit chunks??

That is because every 4 digit binary number corresponds perfectly with one of these new fangled hexadecimal numbers.

base 2	base 16	base 2	base 16
0000	0	1000	8
0001	1	1001	9
0010	2	1010	A
0011	3	1011	B
0100	4	1100	C
0101	5	1101	D
0110	6	1110	E
0111	7	1111	F

This is great because we can take LONGGG strings of binary and quickly convert them into a much easier to read, write, and say form.

Convert 1010 1101 0011 1001b into hexadecimal

This is actually very easy, we first lookup 1010b from our chart: 0xA

1101b = 0xD

0011b = 0x3

1001b = 0x9

Put them all together and you get the answer: 0xAD39

Convert 0x2F into binary

0010 1111b

Easy enough, right?

"I though computers only understood binary?"

That is true. But humans and computers are much better faster at converting hexadecimal numbers into their binary equivalents. For this reason hexadecimal is a convenient way of entering constant numbers in code.

Understanding Binary: Math

Mon, 27 Jun 2011 21:38:29 -0700

Though not as important as understanding binary in general, looking at some simple math in binary will allow you to conceptualize some of the operations that you will be working with on a regular basis.

Addition

In base 10, addition is trivial until you need to awkwardly overflow to the next digit, that is to "carry". For example, if you add 1 to 9, you need to add a digit, and "carry" a 1 into the next digit.

The same thing happens in binary, but unfortunately, it happens a lot more frequently. Since a digit is only 1 or 0, there is a roughly 50% probability that you will need to "carry" to the next digit. Worse yet, you will often find yourself needing to carry more than one time... Example, in base 10, adding 1 to 99, you add 1 to 9, carry one into the next digit and end up adding 1 to 9 again, carrying again to come out to 100.

You can always add in stages, so if you need to add 121 to 99, you can break it up into 121+9, and then whatever that is you add it to 90. When you think about doing it on pencil and paper you typically break it into stages based on digits.

121+9 = 130

130+90 = 220

Add 1001b to 11b

1001b + 1b = 1010b

1010b + 10b = 1100b

Subtraction

Just like addition, but you need to "borrow" if you don't have enough in the first number to subtract.

Honestly, subtraction is trickier to do and I'm trying to keep this pretty brief and general so I'm going to skip over the real details here. But if you'd like to learn more about it, here are some binary subtraction examples. (Note that when you borrow 1b from the higher digit you end up with 10b in the lower digit i.e. 2)

Multiplication

Do you like adding binary numbers? Want to do it as many times as you have digits in the smallest of the two products?

Multiply 1001b by 101b

1001
x101

001001
000000
100100

101101b

That probably needs some explanation. Basically, just like base 10 multiplication, you break the whole multiplication operation up into 3 simple multiplication processes and 3 additions. Every time you multiply a number by 0, it is 0, and by 1 is the original number. The multiplications are truly trivial. If its a 1 in the digit in question you copy down the top number and shift it over as many digits as you have already multiplied. (I added bolding around the actual number we wrote down, and padded all the numbers with zeroes to keep everything lined up.)

Special Case: multiplying by 2 (10b)

In base 10, the easiest number (besides 1 or 0) to multiply by is by 10. Multiplying by 10 is something most people can do in their heads without even thinking about it. And if you were looking at the number on a computer you'd probably just copy, paste, and add a 0 to the end.

Multiplying by 2 in base 2 is exactly the same thing. You just "shift" the number to the left one digit and add a 0.

Multiply 1110 1101 0101b by 10b

0001 1101 1010 1010b (that was so easy it took me longer to "rebalance" the 4 digit spaces, than to even consider the answer)

Whats with the groups of four binary digits?

Well, just like in decimal numbers we often put a comma (or period) after every 3 digits, you often see groups of 4 binary numbers grouped. We will be going over this notation and the reasons when we go over hexadecimal numbers.

Division

Division gets messy and is similar in this way to subtraction, if you want to learn the nitty gritty, here is an example algorithm on binary division.

Special Case: dividing by 2 (10b)

As you may have guesses, this is the opposite of that neat multiply by 2 trick we just went over. With 1 simple exception...

Right "shifting" the number is only perfect if the number is even, that is to say that it doesn't end in 1. This is just like if a number ends in any number but 0 and you divide it by ten there will be some decimal fraction remaining.

Divide 0001 1110 1000b by 10b

1111 0100b

Don't get discouraged if a lot of this is going over your head. I'd doubt any of it is required to be a great programmer. If anything, as you go on, certain aspects of programming will probably jog your memory about this post.

Ready For Sale (Again)

Fri, 24 Jun 2011 16:02:22 -0700

After a couple week delay all of my apps are back up on the iTunes App Store. Thats right, not just Statistical Free. As it turns out when they say "Bank Pending", they mean, "go into contracts and view/submit them all again."

Understanding Binary: Counting

Wed, 22 Jun 2011 21:11:23 -0700

I personally believe that a basic, if not strong, understanding of the binary (or base 2) counting is crucial to understanding how computers work. And, thus, to being a good programmer.

Counting in base 10

Before going into binary we should take a moment to think about something that should be completely natural. I'm speaking of how you count and do some simple math in base 10 or decimal counting.

Numbers in base 10 are simply the numerals 0-9. If you have a single digit you can only count to 9, thats 1 less than you can actually count on your fingers (assuming you don't have any extras)!

If you want to count beyond 9 you need to have more digits. Every digit you add on the left, you can count roughly 10 times as high as you could before. (e.g. 99 vs 9, 999 vs 99)

How high could you count using your fingers and your toes? (assuming the dexterity)

Well the answer isn't 20, but if you've been paying attention... 99 shouldn't surprise you. Here is how...

You start off counting normally on your hands up to 9, then your hands go back to 0, and you stick up a single toe. (I don't think I can physically do this, but you get the idea) You repeat this process putting up the second toe when you go from 19-20, and just keep going until 99.

You might be wondering, "hey I've got a finger and a toe that I'm not counting with, shouldn't I be able to count higher than 99?" Why yes, if you want to use base 11, you could count to 120 (11^2 - 1)but thats beyond the scope of this discussion and not natural to most people at all.

Counting in base 2

Base 2 only has the numerals 0 and 1. With a single digit you can only count to 1, thats it. To count higher you need to add another digit. But that only lets you count to 3, which isn't much better. How far can we count with 4 digits of binary?

Decimal	Binary
01	0001
02	0010
03	0011
04	0100
05	0101
06	0110
07	0111
08	1000
09	1001
10	1010
11	1011
12	1100
13	1101
14	1110
15	1111

(for now I'm going to put b behind every number that is explicitly binary.)

Phew I bet you didn't read the whole thing so I'm not sure why I bothered typing it all out. The pattern is pretty obvious. Just like when you get to, say, 100 in decimal and start counting up the lower 99 again. When you get to say 1000b you get to count up the lower three digits in exactly the same way.

How high can you count on your fingers and toes using binary?

1048575 Surprised? (1048575 = 1111 1111 1111 1111 1111b a 20 'bit' number)

If we used 4 fingers, the above chart gets us to 15

5 fingers? 31

10 fingers? 1023

You can see just how fast this is growing. The relationship is (base^numOfDigits -1)

2^5 = 32, 32-1 = 31

2^10 = 1024, 1024-1 = 1023

2^20 - 1 = 1048575

I couldn't make it, though I've never tried. Counting on a single hand from 0 to 15 or 31 is not too much of a challenge and I encourage you to try it.

Why don't we learn to count on our fingers in binary then?

The fact is that binary counting on fingers is more efficient because we can represent a single digit LITERALLY with a single digit (finger). Working with written binary numbers is more cumbersome, to count over 100 takes 6 binary digits!

Additionally, we are not digital processors. We can generally handle more data than a simple YES/NO or 1/0. Binary numbers are very verbose when compared to our 0-9 counting system, which makes binary more error prone, and more time consuming to work with.

Continue on with Understanding Binary: Math...