We Should Be Using Base 6 Instead

Last updated:

Occasionally you might come across someone who believes that it would be better for us to count in a base other than 10. Usually people recommend base-12 ("dozenal"); compsci people sometimes recommend base-2 (binary) or base-16 (hexadecimal). My personal opinion is that all of these have significant downsides, not worth trading out base-10 for, but that there is a substantially better base we should be using: base 6.

Let's explore why.

(Warning, this post is long and definitely not edited well enough. Strap in.)

Bases Are Arbitrary

First of all, there's nothing special about base-10. Powers of 10 look nice and round to us because we use base-10, but we can use any other base and get just as round numbers. Base 6 has 106, 1006, etc. (Those are 3610, 21610, etc; on the other hand, 1010 and 10010 are 146 and 2446. Converting between bases will usually produce awkward numbers no matter which base you start with.)

Why do we use base-10, then? The obvious answer is that we have 10 fingers. Counting off each finger gives us one "unit" of 10 things, and that unit-size carried over until we invented positional notation, where it froze into the base-10 we know today.

If we invented positional notation earlier, tho, then our hands could have supplied a better base - each hand can count off the values 0, 1, 2, 3, 4, and 5, which are exactly the digits of base-6. Two hands, then, lets you track two base-6 digits, counting up to 556, which is 3510!

Bases Are Significant

On the other hand, there are important qualities that do differ between bases.

The most obvious is the tradeoff of length vs mathematical complexity. Binary has trivial math - the addition and multiplication tables have only four entries each! - but it produces very long numbers - 10010 is 11001002, 7 digits long! On the other hand, using something like, say, base-60 would produce pretty short numbers - 1,000,00010 is only four digits long in base-60 ([4, 37, 46, 40]), but its multiplication table has 3600 entries in it.

When evaluating the tradeoffs of long representations vs complex mental math, it's important to understand a little bit about how the brain actually works for math. In particular, we have a certain level of inherent ability in various domains - short-term memory, computation, etc. Overshooting that ability level is bad - it makes us slower to do mental math, and might require us to drop down to tool usage instead (writing the problem out on paper). But undershooting it is just as bad - our brain can't arbitrarily reallocate "processor cycles" like a computer can, so when we undershoot we're just wasting some of our brain's ability (and, due to the tradeoffs, forcing something else to get harder).

So, we know from experience that binary is bad on these tradeoffs - base-2 arithmetic is drastically undershooting our arithmetic abilities, while binary length quickly exceeds our short-term memory. Similarly, we know that base-60 (used by the Babylonians, way back when) is bad - it drastically overshoots our arithmetic abilities while not significantly reducing the length of numbers, at least in the domain of values we care about (in other words, less than a thousand or so). So there's a happy medium somewhere in the middle here, and conveniently the geometric mean of 2 and 60 is base-11. Give it a healthy ±5 range, and we'll estimate that the "ideal" base is probably somewhere between base-6 and base-16.

Memorization Complexity

But arithmetic complexity, the ease or difficulty of doing math, is more subtle than just a simple length comparison. Some numbers are very easy to do math with in a given base; others are hard. For example, in base 10, it's easy to do math involving 2 or 5, but very difficult with 7.

Exactly which numbers are easy or hard to do math with, and what % of values are easy or hard in a given base, depends on some fundamental arithmetic qualities of the base. Some bases are way worse!

First, addition is more or less equally easy in all bases. Each "row" of an addition table is identical - it's just successive numbers, starting from some offset. Larger bases require us to memorize a few more patterns to do addition quickly, but it's not a significant factor between bases.

Multiplication is where bases really show off. Each row in your times table is totally different, with its own patterns and complexity: some repeat quickly, like the 2s row in base-10 quickly going 2-4-6-8-10 and then repeating with 12-14-16-18-20; others are complex the whole way, like 7.

While some rows are easier to memorize than other (and we'll get to that effect in the next section), overall you have to memorize each row separately, which means the size of the multiplication table matters. Unfortunately for larger bases, this scales up quadratically.

In a given multiplication table, the 0 and 1 rows are trivial and not actually worth counting as "memorized". Similarly, because multiplication is commutative (3×5 and 5×3 are the same), we only actually have to memorize ~half of the values (the diagonal still needs to be fully memorized, tho).

Given these facts, base 10 requires you to memorize 36 individual values. Base 12 requires 56, about 50% more; base 16 requires 105 values, triple that of base 10! On the other hand, base 8 needs only 22, about 2/3s of base 10, and base 6 needs a mere 10 values to be memorized. Base 6 numbers are on average about a digit longer than base 10, but it compensates by making mental math very easy to do!

Arithmetic Complexity

Now let's get down to the specifics - some rows in the multiplication table are harder than others, and which ones are hard or easy varies based on the numeric properties of the base.

There are several ways to talk about this difficulty, but they all end up drawing roughly identical conclusions, so I'll just talk about the simplest: an easy test for how hard a particular number is to do math with in a particular base is to look at how long its unit fraction is when written in that base.

For example, in base-10, 2 is very simple to work with, and its unit fraction, 1/2, is written as 0.5, which is as short and simple as you can get. The same applies to 5: 1/5 is .2, super easy. And harder numbers have harder decimals: 1/7 is .142857 (with underline indicating repeated digits) - six digits with repetition, phew!

Here's the full base 10 set, for the values 2-12:

FractionBase 10
1/2 0.5
1/3 0.3
1/4 0.25
1/5 0.2
1/6 0.16
1/7 0.142847
1/8 0.125
1/9 0.1
1/10 0.1
1/11 0.09
1/12 0.083

What we see here should accord pretty well with your intuition: 2, 5, and 10 are pretty trivial, with their single-digit decimal form; 4 is a little harder, with 2 digits; 3 and 9 are single-digit but repeating, so probably roughly equal in difficulty to 4; 6 and 8 are both a good bit harder than anything so far; and 7 is just garbage. Numbers higher than 10 are all at least moderately difficult.

Now that we're familiar with the table, here's the same results for several more bases:

FractionBase 6Base 8Base 10Base 12Base 16
1/2 .3 .4 .5 .6 .8
1/3 .2 .25 .3 .4 .5
1/4 .13 .2 .25 .3 .4
1/5 .1 .1463 .2 .2497 .3
1/6 .1 .125 .16 .2 .2a
1/7 .05 .1 .142857 .186a35 .249
1/8 .043 .1 .125 .16 .2
1/9 .04 .07 .1 .14 .1c7
1/10 .03 .06314 .1 .12497 .19
1/11 .03134… .05642… .09 .1 .1745d
1/12 .03 .052 .083 .1 .15

(I've only included five of the eleven possible bases under consideration between 6 and 16. All the odd bases are eliminated right off the bat; you can't even tell if a number is even on quick sight, and so they have a ton of repeating decimals and other bad rows. 14's a little better, but it's uniformly worse than any of the five I highlighted above, so it's not worth even considering; being divisible by 2 and 7 makes for bad arithmetic.)

I've color-coded the entries above according to how difficult they are, so you can see at a glance how each base does.

  • Right off the bat, 8 looks like a bad base. An orange for 3 is pretty much enough to rule it out immediately - hard math for such a low number is really annoying - and the rest of the numbers don't even come close to making up for that. Powers of 2 just aren't great, since not many numbers divide them evenly. Scratch it off the list.

  • We also see immediately that base 10 isn't very good - it's got several oranges and a red fairly early, at relatively low numbers (and we use lower numbers more often, so that's bad!).

  • Base 16 does better than I would have expected, with plenty of early greens and yellows. (Base 16's only prime factor is 2, but the factors of the largest digit are also important, and luckily 15 is 3×5 so it covers for 16's flaws.)

    However, the table leaves off the values 13-15, and it's important to evaluate all the single-digit rows for a base; if we included them, they'd all be orange or red. Overall it looks very slightly better than base 10 for low values, but slightly worse for high values; we'll call it even with base 10 for the nice benefit base 16 would bring in the computer age.

  • Base 12 comes out looking pretty nice at first - the first several are all green - but then it hits a hard pair of reds at 5 and 7, which is pretty unfortunate. 5 is a pretty small and commonly-used number, so making arithmetic with it difficult is a pretty bad thing. Besides those two reds, tho (and the one additional red at 10), the rest of the numbers are pretty great, all yellows or greens (and the 1/8 and 1/9 yellows are both "easy" yellows, exactly half or a third between .1 and .2). Despite the unfortunate red at 5, it's pretty clear why 12 is often considered better than 10.

  • Base 6, tho, obviously comes out on top here. Not a single red until 11, which no other base can boast, and even its oranges wait until 7 to show up. And some of its yellows/oranges are right on the edge of lower categories - .13 and .043 are similar to .15 in decimal, exactly halfway between shorter values (.1 and .2, or .04 and .05), which makes them easier to work with than the naive analysis would suggest.

Based on this analysis, base 6 definitely has the easiest arithmetic.


Intuitions around primes just seem to be easier to develop in base-6, too.

In decimal, primes all end in 1, 3, 7, or 9. That's enough digits that people often don't even consciously realize this fact. Heximal primes all end in 1 or 5; approximately the same % of the digits, but a small enough absolute number that it should be intuitively obvious right away.

Perhaps more importantly, that last-digit-of-primes thing is due to 10 being easily divisible by 2 and 5; but it's not easily divisible by any other primes, most notably 3 or 7. You have to do the add-the-digits trick to test for 3-divisibility, and there's no trick for 7, you just have to do full division and see if there's a remainder. This means that it's simply not obvious whether or not a lot of numbers are prime, even small ones; you can trick a lot of people by asking them to quickly tell you if 57 is prime or not (most people will call it prime at first glance, but it's 3*19).

Heximal, tho, has the trivial last-digit test for 2 and 3, the "add all the digits" test for 5, and a moderately easy "alternate adding and subtracting the digits" for 7 (notably, meaning that 116, 226, 336, 446, and 556 are all divisible by 7, like how 11 works in decimal).

This difference seems small, but still significant.

Length of Numbers, and Digit "Breakpoints"

As mentioned earlier, binary is a bad base for humans, because it produces very long representations. Humans have a "difficulty floor" for dealing with individual digits, so having a long number full of very-simple digits doesn't actually trade off properly; you still end up paying a larger "complexity price" per digit, times a long representation, for a very complex result.

In base-10, numbers up to a hundred use 2 digits, and numbers up to a thousand use 3 digits. Base-6 is fairly close to this: 2 digits gets you to 36, 3 to 216, and 4 to 1296. Since we don't generally work with numbers larger than 1000 in base-10 (after that we switch to grouping into thousands/millions/etc, so we're still working with 3 or less digits), you get the same range from base-6 by using, at most, 4 digits. That's only gaining one digit; combine that with the vastly simpler mental math, and you're at worst hitting an equal complexity budget to base-10.

Tho it's less accurate than base-10, we can still use 4 heximal digits (129610) as a group approximately equal to 10 binary digits: the kilo- prefix would be 1,00006, just like it's 100010; mega- would be 1,0000,0006, etc.

Orders of Magnitude

In general, too, an order of magnitude in heximal is more useful than in base 10; it's a smaller, more usable number, and two orders of magnitude is great, too.

For example, decimal time has never caught on because if you divide the day into groups of 100, the hour/minute/seconds are too small (new-hour is ~15 old-minutes, new-minute is about 10 old-seconds, new-second is about .1 old-seconds). But if you divide them into 10 it's too course; going down three levels to the new-second would still leave you about 1 1/2 old minutes! You need to either do a mixed-base system of 10 hours, 100 minutes, 100 seconds (awkward, and not much better than our 24/60/60), or switch to five time divisions between "day" and "second".

On the other hand, heximal time works great with two digits per division. 1006 hours per day means each is 40 old-minutes long, which is still useful for the same purpose that old-hours are; 1006 minutes per hour means each minute is ~66 old-seconds, almost exactly on target; 1006 seconds per minute, then, puts the second at about two old-seconds, which again is about as useful as old-seconds are.

(This coincidentally means we retain the current time intuitions, like ":30" is half-past, a third of an hour is 20 minutes, etc., even tho the number denoted by "30" or "20" is different in old time and heximal time! This ties together counting numbers and time numbers, too, making everything easier for children to learn, as it all works together in coherent systems.)

We can similarly use heximal metric units, which would have made the transition from imperial units much easier. After all, imperial has 12 inches to the foot, and 3 feet to the yard, so 36 inches to the yard in total. That's our old pal 1006! And a yard is very close to a meter, so a "metric inch" would be just slightly larger than an imperial inch. Keeping to the new "kilo- means 4 heximal digits" practice, a heximal kilometer is about .8 imperial miles, much closer than the .6 miles of a decimal kilometer, again easing adoption.

And heck, the metric system is kinda inconvenient anyway! 1000x steps are large; it means there's a huge difference between each "base" unit as you move up and down the prefixes. (Millimeter is too small for most everyday measurements, but meter is too large. Etc.) And because each prefix is 3 digits, there's no useful "halfway" breakpoint to use either; we just kinda arbitrarily use the centimeter for everyday measurements because we have to, but it's awkward when doing unit conversions.

But heximal metric does have a useful halfway breakpoint: 2 digits! Thirty-ish of something is a great number to have, as we established with time. So just like the heximal inch is the useful halfway point between the meter and the (heximal) millimeter, we would even have a useful breakpoint between the meter and the kilometer, 1006 meters, or the heximal chain (after the imperial chain), which is about 20 meters).

With both of these together, metric conversions involving time and other units finally become easy: 20 km/hour == 20 m/s (and 20 chains/minute!), no more of that awkward division by 60, 3600, or 86400.

In Conclusion

So, base 6 has more useful divisors, making it easy to divide by many small numbers. It's got a smaller (and thus easier to memorize/use) addition table, and a multiplication table that's not only substantially smaller than base-10, but substantially easier in very significant ways, making mental arithmetic much simpler. We can cover a similar range of numbers with just three digits, so it even looks similar to base-10 when the numbers get large enough to need scientific notation.

If you ever find a time machine, let me know so I can fix this. ^_^

(a limited set of Markdown is supported)

That would give us 20 months a year, 50 days a month (roughly), 120 minutes per hour and 40 hours per day. Weeks are still odd with 11 days, but not any worse than decimal 7. I'm sold.


(a limited set of Markdown is supported)

Re #1: Yeah, that's all assuming we change nothing else about the organization of our times.

Note that it's 140 minutes/hour, not 120.


(a limited set of Markdown is supported)