Variable Memory

1.1 Variable Memory

Its really hard to start at any one spot, but a very important concept to understand in programmig beyond logic is the idea of how to use the computer’s memory. In order to do anything in any program, you will eventually have to reserve memory on the computer to be used by your program. This is done by declairing “Variables.” Variables as the name would suggest are things that stand for…things. Just like your old algrebra, when you would put in the letter “X” to stand for any number, you can declair a variable in your program to stand for any number.

What this is doing is telling the computer to reserve a set of memory for the programs uses of a certain size. The actual location of that memory is purly random, and once you actually declair it could contain any sort of information. This is called “Ininitialized Memory”…basically…just because you reserve that bit of memory doesn’t mean that some other program didn’t just release that memory, and it could have a bit of information still sitting there. Because of this, the standard practice is to ALWAYS put an initializing value in a variable..no matter what the variable is or might end up doing. It just makes sure that the only information you are using is stuff that you put there

1.2 Counting in Computer Land.

It is important to understand that this reserved bit of memory is placed in a random spot in memory. That spot’s size depends on the programming language you are using or what compiler you are using. It all is because of how computer’s count: in 2’s. Just picture that you can count, but only as high as the number of fingers you have. If you just use one finger for one number, then obviously you’re only gonna make it to 10. However…if you use a special “code” you can make your right hand count as “1’s” (each finger is worth 1) and your left hand count as “10’s” (each finger is worth 10) and suddenly, you can count to 99. Try it out:

Computers count using just groups of 1’s and 0’s. This is usually in groups of eight (1 byte) but lets look at the first four bits.

0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 = 10
1011 = 11
1100 = 12
1101 = 13
1110 = 14
1111 = 15

Zero through fifteen. Now..lets get even trickier. Lets reduce that down to one digit each…so the same 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

So, by this table..if I counted to E, I really mean 14. Now lets put two together; F2 would be worth 242…that’s 16 * 15 + 2 (the position that “F” stands is worth 16 for every one…so that’s 16 * 15). CA would then be worth 202, being 16 * 12 + 10. This is called Base 16 counting, or Hexadecimal.

Here’s how it works: No matter what base you are in..if its base 10 (what we normally count in), base 2 (that computers us) you can find out what the value is from the position the digit is in. So if it’s base 16, the first position is worth 16^0. The second position is worth 16^2. The third position is worth 16^3, and so on. So, 931 in base 16 is worth (16^2*9) + (16^1*3) + (16^0*1) or 2353.

But what happens if you run out of fingers? If you only have four bites to count with, what happens if you ned to count to 16 or 17? The short answer is…you don’t. If you go beyond the bounds of the memory you are using, it encounter either a overflow or an underflow. For instance, if you add one to F (or 1111) that is 15, it will become 0 (0000). Or if you subtract one from 0 (0000) it will become F (or 1111). However, in many compilers, these over or underflows will be captured and return an error.

1.3 Other types of Encoding

A normal 16-bit integer is between –32,678 and 32,767. This is done by actually using the first 15 bits for counting, then the last bit as the “Signed” bit. This tells the compiler if the number is either positive or negative. So what if you don’t need to count to negative numbers? You can then use an “unsigned” integer, counting from 0 to 65,535—doubling your range.

Floating-point numbers are trickier, because they are stored in a different way. No matter what the size of the floating-point number, it is divided into three parts: the signed bit (for positive or negative value), the base number and the mantessa. So the result is that similar to scientific notation: -1 * 153 * 10^2, where the 153, -1 and 2 getting stored. This can cause problems when you dealing with rounding. Try declairing 2 variables, and in one just put the number 0.33. In the other, put the number 100, but divide it by 3. Print these two numbers out. This is a direct reason because of how floating-point numbers are stored. There are ways around this, but that can wait until later.

1.4 Flavors of Memory

So what are types of memory? There are different types with different compilers. Here is one example.

There are others, but this is just one example of one language in one compiler. Therefore…its best to check the compiler you are using. The important idea to walk away with is that when you create variables you have limits. Of course, this means that you will need to know what you will be using first (are you just counting from 1-10? Then a Shortint would be good. Are you counting population of California? Maybe a Longint would be better) then check your compiler’s available types for what to use.

1.5 Bloatware verses Just Enough

So why use a “Shortint” at all? If I can only count between –128 and 127 with that one, so what good is it? Why not use a Longint for everything? This argument is very commong and the result is more often than not, to just use the biggest memory available. The result is what is commonly known as “Bloatware”; software that takes up tons of memory just because it can. The consequences of having huge available memory is that programs are getting created to fill that memeory…if it needs it or not. So if you can use a short int….you should. For no other reason than to be efficient. Fast, efficient and compact means a stronger more useful program.