I would prefer base-12; it has a lot of benefits. See http://en.wikipedia.org/wiki/Duodecimal, especially http://en.wikipedia.org/wiki/Duodecimal#Comparison_to_other_...

Instead of changing our clocks, we could just change our numbering system. Having 50 (that's 5 x 12) seconds per minute, 50 minutes per hour, and 20 hours per day seems perfectly reasonable.

I'd like to use base-11. Prime numbered bases eliminate lots of special cases.

Choosing a radix is a balance between the number of prime factors (and brevity) and the number of symbols to keep track of. I think twelve strikes a good balance as well.

In that case 3 is your number. (Because it's the closest number to e, 2.71)

There is a currency based on it (with the provably least number of coins necessary to make any kind of change), ternary logic, balanced ternary is especially cool, etc.

Why is being close to e a good thing?

Actually, the best number depends. Basically, you want to have as few operations as possible, but you also want them easy.

Having base b for number n, you need log_b n digits where each digit is an element of (0..b-1). So working on those representations takes something like f(log_b n, b) operations. Where the function f depends on the operation you are looking at.

A good base should keep f small in relation to all n.

One very natural choice for f, I can't remember which at the moment, leads to e being the best base in theory---so 3 being good in practice.

If you are working with something like trees on disk (yes, data structures are very intimately related to numbering systems---read Okasaki's Purely Functional Data Structures for more information) a very big b, i.e. branching factor in this case, like 1024 is useful: Loading a new digit/node from disk into memory takes a long time, but once it's in memory, your operations will be fast.

But 12 only gains you one more factor that's not a power of 2, and is 30 times more difficult to implement (operation tables have 144 cells for base 12, compared to 4 cells for base 2).

That's why you should use the digits -n/2 to +n/2 for base n. That shrinks the tables by a factor of four.

Oh no, I just knew someone would come and argue for balanced n-ary on this thread :)

Most of us have 10 fingers, which makes counting easy (although you can count to 12/20/24/40 on your fingers too, I admit).

Why stop there? Lets have base 1024, you can count to that on your fingers too!

http://en.wikipedia.org/wiki/Finger_binary

No, you can represent it with your fingers but not count it. By 'count' I mean an ordinal traversal of the sort you teach kids.

Use gray code.

Good luck teaching that to a 4 year old, or someone who's barely numerate. Higher bases are better for learning counting because the person can count a variety of small quantities without needing to understand the concept of a number base. It's not that I don't approve of binary counting by hand, but it's hardly useful for beginners or primitive societies.

Oh, for that application, my suggestion of gray code is even worse then binary.

Though actually, you are not really arguing for a large base, but for unary. (Or a mixed unary-large base system.)

Because it makes it so that the number four has another meaning that, for whatever reason, people can't get past.

I've tried to explain it to people before, but we never manage to count past four without someone laughing.

Then they're missing a far better number: 132

Powers of ten are easy to manage in base 10?

Yeah, but once you move everything to base 2, you won't have to deal with those pesky powers of 10 anymore ;)

Base 2? Nonono, everything is always base 10.

(If you don't get it, think about it longer.)

Not in gray code.

We should also use base-8 number system! http://infoverse.org/octomatics/octomatics.htm