I think I know where the miscommunication is happening. First of all, you are right: the number doesn't change when you change bases or representations. Unfortunately, you are wrong in thinking that it does reduce the amount of information encoded in the number: changing base or representation also doesn't change the amount of information in the number. Let me explain.
Let's start with your 127 MB file example, but let's make it 128 MB for the nice roundness. I imagine that we can agree that 128 MB = 2^7*2^10*2^10*2^3 = 2^30 bits. I think we can also agree that with this much bits you can describe 2^(2^30) (note the nested exponent) distinct, unique numbers (that's a huge amount!), and the largest number that can be expressed would be 2^(2^30) - 1. Of course, you don't need to represent the number as a binary number. If you want to represent the same number of unique distinct numbers as, say, a four-digit number (just because it's easier math than your 3-digit example), this would mean that you need 4 digits of (2^30)/4 = 2^28 bits each, each of which can represent one of 2^(2^28) distinct, unique numbers. You could say that you have created a number represented by four base-2^28 = base-268435456 digits. You now only need to write out just 4 (be it complicated) glyphs to paper. OK sofar. Now you suggest that by writing only four digits, instead of the 2^30, you can reduce the data volume needed to store such large numbers. Unfortunatly, that won't work.
Here's the catch: there are 2^(2^28) distinct glyphs necessary, one for each of the 2^(2^28) possible numbers. Each of these glyphs must be completely unique, and completely distinguishable from all the others. So how are you going to distinguish your glyphs? You do that by giving glyphs characteristics when you write them, and check for those characteristics when you read them. These may include color, shape, rotation, etc. Now, suppose you have a device that prints colored dots, and another device that can read dots and determine their color. With these you can read and write glyphs that consist of colored dots. The dot is the smallest unit we can print or scan, so the most efficient we can go is to build glyphs out of dots, right? I doesn't even matter whether we arrange the dots in lines, or squares, or something esle, we just need to define some group of dots as a glyph.
Suppose we can distinguish C distinct colors (for instance C=2^48, for 48 bit scanners, assuming they are perfectly accurate). After reading the first dot, we still don't know what glyph we are reading, but we have narrowed it down to all glyphs that start with a dot of that color, which reduces the remaining search space by 1/2^48. Easy so far. How many more dots do we need to read to narrow down our search to a single glyph? After having read N dots, we've narrowed the search space down to S(N) = (2^(2^26))/((2^48)^N). Solving S(N) = 1 gives N = 2^26/48. That is how many dots you need to print one single glyph (quite a lot of dots). To print four glyphs, you'll therefore need 4*N = 4*2^26/48 = 2^28/48 dots. Agreed sofar?
Then here's the punch line: that is exactly the same number of dots you would need to directly encode our original 2^28 bits binary file: 48 bits per dot (2^48) gives 2^28/48 dots. So you have not reduced your data by converting to a different base.
To summarize: indeed, you are right, a number stays a number, no matter in what base you represent it. However, the amount of information a number can encode does not change either. Using a higher base means that you save in the number of digits you need, but the complexity of your glyphs will go up accordingly, and you'll end up with the same total amount of information. That's also why binary works and is used : if it doesn't matter what base you have, go with the simplest: base 2.
Slashdot Mirror
I think I know where the miscommunication is happening. First of all, you are right: the number doesn't change when you change bases or representations. Unfortunately, you are wrong in thinking that it does reduce the amount of information encoded in the number: changing base or representation also doesn't change the amount of information in the number. Let me explain.
:)
Let's start with your 127 MB file example, but let's make it 128 MB for the nice roundness. I imagine that we can agree that 128 MB = 2^7*2^10*2^10*2^3 = 2^30 bits. I think we can also agree that with this much bits you can describe 2^(2^30) (note the nested exponent) distinct, unique numbers (that's a huge amount!), and the largest number that can be expressed would be 2^(2^30) - 1. Of course, you don't need to represent the number as a binary number. If you want to represent the same number of unique distinct numbers as, say, a four-digit number (just because it's easier math than your 3-digit example), this would mean that you need 4 digits of (2^30)/4 = 2^28 bits each, each of which can represent one of 2^(2^28) distinct, unique numbers. You could say that you have created a number represented by four base-2^28 = base-268435456 digits. You now only need to write out just 4 (be it complicated) glyphs to paper. OK sofar. Now you suggest that by writing only four digits, instead of the 2^30, you can reduce the data volume needed to store such large numbers. Unfortunatly, that won't work.
Here's the catch: there are 2^(2^28) distinct glyphs necessary, one for each of the 2^(2^28) possible numbers. Each of these glyphs must be completely unique, and completely distinguishable from all the others. So how are you going to distinguish your glyphs? You do that by giving glyphs characteristics when you write them, and check for those characteristics when you read them. These may include color, shape, rotation, etc. Now, suppose you have a device that prints colored dots, and another device that can read dots and determine their color. With these you can read and write glyphs that consist of colored dots. The dot is the smallest unit we can print or scan, so the most efficient we can go is to build glyphs out of dots, right? I doesn't even matter whether we arrange the dots in lines, or squares, or something esle, we just need to define some group of dots as a glyph.
Suppose we can distinguish C distinct colors (for instance C=2^48, for 48 bit scanners, assuming they are perfectly accurate). After reading the first dot, we still don't know what glyph we are reading, but we have narrowed it down to all glyphs that start with a dot of that color, which reduces the remaining search space by 1/2^48. Easy so far. How many more dots do we need to read to narrow down our search to a single glyph? After having read N dots, we've narrowed the search space down to S(N) = (2^(2^26))/((2^48)^N). Solving S(N) = 1 gives N = 2^26/48. That is how many dots you need to print one single glyph (quite a lot of dots). To print four glyphs, you'll therefore need 4*N = 4*2^26/48 = 2^28/48 dots. Agreed sofar?
Then here's the punch line: that is exactly the same number of dots you would need to directly encode our original 2^28 bits binary file: 48 bits per dot (2^48) gives 2^28/48 dots. So you have not reduced your data by converting to a different base.
To summarize: indeed, you are right, a number stays a number, no matter in what base you represent it. However, the amount of information a number can encode does not change either. Using a higher base means that you save in the number of digits you need, but the complexity of your glyphs will go up accordingly, and you'll end up with the same total amount of information. That's also why binary works and is used : if it doesn't matter what base you have, go with the simplest: base 2.
Hope this helps relieve the argument somewhat