michael_nielsen

Of course, in practice we don't want to write out all the A's on the left. So we'll just adopt the convention of taking those as given. In other words, something like: BD really means ...AAAABD, but the A's on the left are implied.

Now there's a bit of a problem, which is this convention makes ...AAAA be written as just a blank. Obviously that would be unreadable. So we'll introduce an exception: for that, we'll write A, just as a kind of placeholder.

I don't claim, by the way, that this "universal counter" approach is necessarily _more_ obvious than what we were doing earlier. But it's at least plausible as an alternate. And it has the benefit that it's an attractively unified system.

Okay, so the way counting goes is: A, B, C, ..., Z, BA, BB, BC,...., and eventually on to BAA, BAB, and so on.

In this system, xy -> (x-1)*23+y. And xyz -> (x-1)*23*23+(y-1)*23+z. Those seem satisfyingly neat, and the pattern continues.

There is still a slightly ugly thing, which is the -1 terms, which show up over and over again. We could get rid of those if we decided to start counting at 1 -> B, 2 -> C, etc.

If we did that, then we'd have xy -> x*23+y, xyz -> x*23*23+y*23+z, and so on for longer strings. That's even simpler, though A is now playing pretty much the role of a placeholder.

At this point a clever designer might be bugged by the use of the alphabet in this number representation. After all, the alphabet is already being used for words! So it'd be better to switch to different symbols to prevent confusion.

The alternate symbols we use are pretty arbitrary. Let's go for A -> 0, B -> 1, C -> 2, and so on. Of course, we could introduce 23 new symbols. But the 23 is actually pretty arbitrary. So let's use just 10 symbols: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.

(Of course, the numeric base we use is pretty uninteresting. Base 10 turns out to have some nice advantages, and also some slight problems. But I think this really is an accidental piece of history.)

With these choices, our number representation is: xyz -> x*10*10+y*10+z. And so on, for larger numbers.

We're very _used to_ this kind of representation. But there's nothing obvious about it at all. Every single thing in the representation can be questioned, and possibly changed. It's fun to try some experiments!

One particularly amusing thing: consider the numbers 132 and 123. The 2 actually has a very different meaning in those two numbers. The fact that _location matters_ is a deep idea.

(I've glossed over 0 in various ways in this account. And over the fact that place-number system pre-dated the romans. If I was more conscientious I'd have talked more about these - they're incredibly deep ideas - but this thread is already long, so I'll keep glossing.)

At this point we have a new numeral system. It's nice in a couple of ways when compared to roman numerals - it doesn't need new symbols to represent larger numbers, and it's extremely compact.

Still, those things perhaps don't seem that important. Certainly not worth replacing an entire piece of intellectual infrastructure with!

But where this number system really shines is in simplifying certain other things you might want to do. For instance, consider addition of the numbers wx and yz.

We have wx + yz = (w*10+x) + (y*10+z) = (w+y)*10 + (x+z). Fiddle with this for a while - it's more work than I want to go through here - and you eventually recover the grade school algorithm for adding two-digit numbers. Do some more work, & you get the n-digit algorithm.

There's a miracle going on here, one we don't notice b/c it's so familiar: I pointed out above that the numerals have very different meanings, depending on their location. But despite this, in the grade-school algorithm we use the _same rules_ for addition, regardless of place!

E.g., in computing 27+38 at some point in the computation we'll use 2+3 = 5; in computing 72+83 at some point we'll also use 2+3=5. That's despite the fact that the 2 and the 3 in the first sum have a very different meaning than in the second sum!

What's responsible for this astonishing fact? If you look back at the reasoning above, you see it's a consequence of associativity, commutativity, and distributivity. That's a pretty huge set of things! And it makes addition _really_ nice in this representation.

In particular, it means that although the numerals have different meanings in different locations, in many ways they continue to _behave_ as though they are in some sense "the same". They're _not_ the same. But they retain many of the same affordances, in modern interface lingo.

You can go through the same kind of thing, trying to figure out how to multiply two numbers: wx*yz = (w*10+x)*(y*10+z) = x*y*10*10 + ... I won't go through it, but you can guess what happens: you get the grade-school algorithm for multiplication.

And, again, even though the numerals have very different meanings in different positions, they have a lot of the same affordances, and so behave in some ways as the "same" object.

You can go through this with long division. Same story.

At this point this new numeral system looks vastly superior to roman numerals. It's exploiting all this structure to get compact representations, which don't require new symbols, & which exploit deep properties of numbers to simplify addition, multiplication, & division. Amazing!

I'm far from an expert on the history of mathematics or its representations. The story above is unrealistic in many ways. Still, I think it gives at least a hint of the incredible mathematical and design insight required to invent arabic numerals.

And, of course, this story requires many incredible earlier insights: words, the alphabet, various ideas about multiplication and addition, and so on.

To finish, a fun question: is there some way to improve still further on arabic numerals? I believe the answer is almost certainly yes! But that's a thread for another day.

A few addenda: (1) as lots of people have pointed out, it'd have been more accurate to name them Hindu-Arabic numerals; (2) the ancient Greeks seem to have known much of this (which I didn't know);