On the question of mathematical problems, the closest thing that comes to mind is digits of pi. In base 10 (or in fact, almost any other base), if you want to know the nth digit of pi, you need to calculate all n-1 digits before it. In contrast, in base 2 (or base 4, or 8, or 16, or…), it’s possible to calculate any digit you want, one at a time.
Oh, and I also once encountered a problem in a program I was writing where it was most natural to work in base 11, but that’s kind of a fluke.
Putting Indistinguishable’s point another way: the thought is that the thing you most want to avoid is not decimals in general, but infinite repeating decimals. And in this respect, base twelve is not really any better than base ten; you get to avoid repeating decimals when dividing by numbers that are factored by three, but you add them when dividing by numbers that are factored by five, so it’s a close to a wash–3 isn’t that much more common than 5. And to get that tiny advantage, you have to learn 20% more digits and memorize a 40% larger multiplication table. Base 6 gets you all of those advantages without any disadvantages except sometimes having one more digit in the decimal place. (Eg. 5/4 is 1.3 in base twelve, and 1.13 in base six. Neither of these seems more complicated to deal with than the 1.25 you get in base ten. 4/3 is 1.2 in base six, 1.4 in base twelve, and 1.333333333 … in base ten, which makes base ten look bad; but 6/5 turns the tables. Or 10/5 in base six. 
)
Unix file permissions.
I see your point, and I would agree, except I disagree with making the base as small as possible. As I mentioned in the paragraph above the one you quoted, I think it’s a balance between being too big to make an unweildy symbol set and being so small as to have the representations become cumbersome instead. I think base 6 is better than 12, 8, or 10 when small and factors is concerned, but by that same logic base 2 is strictly superior because it’s even smaller.
I think base 6 is right about on the line of being too small because it takes more than one digit to represent 6, 7, 8, and 9. When compared to base 12, you also lose 10 and 11. Yes, base 6 can handle 4 roughly just as well (0.13 isn’t that bad compared to 0.3), but I think the larger size of 12 is actually an advantage, not a disadvantage, because the numbers are less cumbersome to work with; hell, I had to learn up to 12 in my multiplication tables in third grade anyway, and that’s probably the worst part of a larger base.
For **SCSimmons’s **point, I don’t think 3 and 5 is a wash. I definitely see 1/3 far more often than I see 1/5, and I even think many of the times I see 1/5 are probably attributable to the fact that we have a base 10 system and 1/5 is a somewhat convenient value. If we had a base 6 or base 12 system, I think we’d probably see a lot of the 1/5 usage get replaced with 1/6 or 1/4.
And yes, I realize there’s a penalty for going to base 12, but I think it’s a bit disingenuous to say 20% more symbols… it’s only 2; hell, no one complains about learning the 26 letters in the English alphabet. I do think the multiplication table is a bit of a drawback but like I said above, I don’t think it’s that bad if they could expect third graders to memorize it now, and I think that is a small trade-off and that it compares favorably to being able to have smaller representations (8 instead of 12 or 63 instead of 203 for what is 75 base 10) and having even 1/4 be slightly simpler doesn’t hurt either.
I think if you look at a lot of numbers we see daily, you’ll find that a non-insignificant portion of them would have smaller representations in base 12 than in base 6.
I would simplify matters and just use base 1.
Of course multiplication is commutative, so you really only need to memorize about half of those cells.
But still, you’re right, base 30 does seem unwieldy. Schoolhouse Rock would never have finished production if they’d had to cover all those cases.
If it’s good enough for people locked up in dungeons, it’s good enough for me!
It’s a balance, like letters in a alphabet. The fewer base units (digits or letters) you have, the easier it is to commit the list to memory. But a small base results in longer combinations (numbers and words).
As an example, if we used a base-26 numerical system with the letters of the alphabet, we’d have over twice as many digits to keep straight. But a thousand would only be ALL, a million would only be BDWGN, and a billion would be only be CFDGSXL.
Now go the other way. In a binary base-2 system, you only have two digits to deal with. But a thousand is 1,111,101,000, a million is 11,110,100,001,001,000,000, and a billion is 111,011,100,110,101,100,101,000,000,000.
But if my math is correct, 1/10 would be the ugly 0.1249724972497…
(That’s 1/12 + 2/144 + 4/(12^3) + 9/(12^4) …)
But I concede that we wouldn’t be using or needing 1/10 very often.
I can tell you weren’t involved in teaching my younger son to read.
I’m actually starting to lean towards base 30. It’ll be harder to learn the times tables, but adversity makes us stronger!
Ah! So did you consider re-writing your program using Java2k? It has native support for base 11.
Nitpick: Avogadro’s number isn’t actually dimensionless; it is in units of mol[sup]-1[/sup] (reciprocal moles).
The rest of this thread is way over my head.
That is debated. Moles aren’t units like the other ones. The Wikipedia article covers this a little:
“Since its adoption into the International System of Units, there have been a number of criticisms of the concept of the mole being a unit like the metre or the second.[6] These criticisms may be briefly summarised as:
amount of substance is not a true physical quantity (or dimension), and is redundant to mass, so should not have its own base unit;
the mole is simply a shorthand way of referring to a large number.”
I like the idea of bases that are products of the first few primes, like 30.
I also am intrigued by the idea of non-integer base systems. Somewhere I heard the argument that base 3 is more efficient in some absolute sense than base 2, because it is closer to Euler’s number “e”, 2.718… No idea if this is accurate or meaningful, but it does sound like the kind of thing e would be clever about somehow. So, wouldn’t there be some special magic about base e math? Or what if each column in a number didn’t get an integer but rather a continuous variable, so there were actually multiple forms of identical numbers?
Or how about a non-base number system that allowed managing enormous numbers better, like mapping 1 onto the first integer, and 2^2 onto the second, and 3^3^3 onto the third, and 4^4^4^4 onto the fourth, and so forth. Then come up with some meaningful intermediate values (analogous to the thought process some clever mathematician of old applied to exponentiation to come up with the idea of logarithms; sadly the name of this brilliant benefactor escapes me).
One computer parameter that has a bit count divisible by 3 is 24 bit color, or actually perhaps several other present and future versions of color, because color (or more accurately the thing we perceive point by point in vision) has three degrees of freedom, like (in typical computer systems) R and B and G.
What modesty to call it Euler’s number, rather than Napier’s constant! (I’ve made a similar joke to you before, but how can anyone resist, when the opportunity keeps arising?)
More seriously, I don’t know what this would mean, “more efficient”. I’m not buying it. However, there is something special about measuring information in base e units, rather than in bits or decimal digits or whatever. [This isn’t to say that base e makes a “more efficient” system of notation, in any sense, whatever that would mean (don’t ask me); the whole point of comparing information measures is to establish certain equivalences between measurement in different bases, keeping in mind the appropriate ratios between different units. The key fact about e is just that there’s an element of naturality to information measurement in base e units which makes it canonical in a way other bases are not, so far as this purpose goes].
The idea is that measuring information magnitude is just another way of measuring probability: learning something that has probability 1/2 is learning 1 bit, learning something that has probability 1/10 is learning 1 decimal digit, learning something that has probability 1/10^3 is learning 3 decimal digits (equivalently, 1 base 1000 digit), and so on. The two concepts are just different scales by which to measure the same thing. However, whereas the probability of a conjunction of independent events is the product of the individual probabilities, we often want to speak of the information magnitude of the conjunction as the sum of the individual information magnitudes; that is, the relation between the probability and information magnitude scales is nonlinear, with multiplication of probabilities corresponding to addition of information magnitude.
Well, whenever two scales are related in this way, we’re talking about an exponential/logarithmic correspondence; information magnitude is logarithmic probability and probability is exponential information magnitude. So choosing a scale by which to measure information magnitude is just choosing a base for logarithms/exponentiation. Measuring in bits is using a base 2 logarithm; measuring in decimal digits is using a base 10 logarithm and so on.
Any base for logarithms/exponentiation is just a rescaling of any other base, of course. But there’s a certain naturality to base e. There are many ways to put the naturality property, but perhaps we should put it in this context like this: as the probability of an event falls from 1, the corresponding information rises up from 0 at some rate; the rate will have units of information magnitude per probability, which is to say, this rate can be considered to be an information magnitude (considering probability as dimensionless). Let us call this information magnitude “1 nat”. And what is a nat, exactly? Well, it happens to be the amount of information contained in an event of probability 1/e (indeed, this is pretty much the definition of e). Thus, we have that the nat scale of measuring information magnitude is equivalent to the base e scale.
Base 3 is interesting especially because you could -1, 0, 1 as your “trits” which makes things interesting.
But I favor either 8 or 16, probably 16. There is, of course, a tradeoff between ease of learnability and efficiency of use. I have two reasons, one inherent and the other utterly fortuitous:
– When I cook, I find the system of gallons, quarts, pints, cups, ounces very useful. I would fill in double quarts and measures of 2 and 4 ounces. I find the halving very intuitive. And, to my knowledge, every (decimal) currency in the world divides its units into steps of 2, 2, and 2 1/2 to make a decade. (The US has consistently ignored the half dollar and two dollar units; I can’t explain that.) Again, the halving, insofar as it is possible, seems to have psychological reality.
– Our calendar is arranged to omit a leap year every 133 1/3 years (three omitted every 400 years). This will result in being one day short every 3200 years when an extra leap year should be inserted. I once calculated how often leap years should be omitted in order to actually match the length of the year. (The length of the day and perhaps the year is not constant so no system could be perfect, even in principal.) And the number I got said that we ought to be omitting leap year every 128 years! And that would be a round number in either base 8 or 16.
I’m surprised. Is this a proven result, or is it just that we know a way to do it in base two and don’t know a way in base ten?
It’s more “efficient” in the following (possibly useless) sense: given an abacus with a fixed set of beads, with what base can you count the highest?
Generally, the answer is given by the function f(n) = n^(K/n) where K is the number of beads on your abacus. Differentiating, then setting equal to zero, we find the maximum at e.
It’s a proven result for power-of-2 bases. (See the Bailey–Borwein–Plouffe formula.)
This algorithm computes pi without requiring custom data types having thousands or even millions of digits. The method calculates the nth digit without calculating the first n − 1 digits, and can use small, efficient data types.
The algorithm is the fastest way to compute the nth digit (or a few digits in a neighborhood of the nth), but pi-computing algorithms using large data types remain faster when the goal is to compute all the digits from 1 to n.
I see that some mod has changed the title of the thread from A Basic Question to A Basic Question [about math].
My guess is that he didn’t get the joke, that “basic” was referring to the thread being about bases.
Sorry I wasn’t clear: I’m interested in the claim that you can’t do this in base 10. Is that proven, or is it just that we don’t know a way?