I was idly musing about number sequences, and the Lychrel algorithm. If you don’t know about this, there’s a good Numberphile video on it: basically, take any number, reverse it, add the two, and if you get a palindrome stop, and if you don’t, keep doing it. So start with, say,
57, reverse to get
75, add them to get
57+75=132, which isn’t a palindrome, so do it again; reverse
132 to get
231, add to get
132+231=363, and that’s a palindrome, so stop. There are a bunch of interesting questions that can be asked about this process (which James Grime goes into in the video), among which are: does this always terminate? What’s the longest chain before termination? And so on.
196 famously hasn’t terminated so far and it’s been tried for several billion iterations.
Anyway, I was thinking about another such iterative process. Take a number, express it in words, then add up the values of all the letters in the words, and do it again. So
15, 14, 5 (
O is the fifteenth letter of the alphabet,
N the fourteenth, and so on), so we add
15+14+5 to get
34, which becomes
THIRTY FOUR, and so on. (We skip spaces and dashes; just the letters.)
Take a complete example: let’s start with 4.
6+15+21+18 = 60
19+9+24+20+25 = 97
14+9+14+5+20+25+19+5+22+5+14 = 152
ONE HUNDRED AND FIFTY-TWO->
15+14+5+8+21+14+4+18+5+4+1+14+4+6+9+6+20+25+20+23+15 = 251
TWO HUNDRED AND FIFTY-ONE->
20+23+15+8+21+14+4+18+5+4+1+14+4+6+9+6+20+25+15+14+5 = 251
251 is a fixed point: it becomes itself. So we stop there, because we’re now in an infinite loop.
Do all numbers eventually go into a loop? Do all numbers go into the same loop — that is, do they all end up at
It’s hard to tell. (Well, it’s hard to tell for me. Some of you may see some easy way to prove this, in which case do let me know.) Me being me, I wrote a little Python programme to test this out (helped immeasurably by the Python 3 num2words library). As I discovered before, if you’re trying to pick out patterns in a big graph of numbers which all link to one another, it’s a lot easier to have graphviz draw you pretty pictures, so that’s what I did.
I’ve run numbers up to 5000 or so (after that I got a bit bored waiting for answers; it’s not recreational mathematics if I have to wait around, it’s a job for which I’m not getting paid). And it looks like numbers settle out into a tiny island which ends up at
251, a little island which ends up at
285, and a massive island which ends up at
259, all of which become themselves1. (You can see an image of the first 500 numbers and how they end up; extending that up to 5000 just makes the islands larger, it doesn’t create new islands… and the diagrams either get rather unwieldy or they get really big and they’re hard to display.2)
I have a theory that (a) yes all numbers end up in a fixed point and (b) there probably aren’t any more fixed points. Warning: dubious mathematical assertions lie ahead.
There can’t be that many numbers that encode to themselves. This is both because I’ve run it up to 5000 and there aren’t, and because it just seems kinda unlikely and coincidental. So, we assume that the fixed points we have are most or all of the fixed points available. Now, every number has to end up somewhere; the process can’t just keep going forever. So, if you keep generating numbers, you’re pretty likely at some point to hit a number you’ve already hit, which ends up at one of the fixed points. And finally, the numbers-to-words process doesn’t grow as fast as actual numbers do. Once you’ve got over a certain limit, you’ll pretty much always end up generating a number smaller than oneself in the next iteration. The reason I think this is that adding more to numbers doesn’t make their word lengths all that much longer. Take, for example, the longest number (in words) up to 100,000, which is (among others)
seventy-three thousand, three hundred and seventy-three. This is
47 characters long. Even if they were all
Z, which they aren’t, it’d generate
47×26=1222, which is way less than
73,373. And adding lots more doesn’t help much: if we add a million to that number, we put
one million on the front of it, which is only another
10 characters, or a maximum added value of
260. There’s no actual ceiling — numbers in words still grow without limit as the number itself grows — but it doesn’t grow anywhere near as fast as the number itself does. So the numbers generally get smaller as they iterate, until they get down below four hundred or so… and all of those numbers terminate in one of the three fixed points already outlined. So I think that all numbers will terminate thus.
The obvious flaw with this argument is that it ought to apply to the reverse-and-add process above too and it doesn’t for 196 (and some others). So it’s possible that my approach will also make a Lychrel-ish number that may not terminate, but I don’t think it will; the argument above seems compelling.
You might be thinking: bloody English imperialist! What about les nombres, eh? Or die Zahlen? Did you check those? Mais oui, I checked (nice one
num2words for supporting a zillion languages!) Same thing. There are different fixed points (
French has one big island until Images of French and German are available, and you can of course use the Python 3 script to make your own; run it as
177, a very small island to
258, 436 pair, and
222 which encodes to itself and nothing else encodes to it, for example.
python3 numwords.py no for Norwegian, etc.) You may also be thinking “what about American English, eh?
ONE HUNDRED ONE, not
ONE HUNDRED AND ONE.” I have not tested this, partially because I think the above argument should still hold for it, partially because
num2words doesn’t support it, and partially because that’s what you get for throwing a bunch of perfectly good tea into the ocean, but I don’t think it’d be hard to verify if someone wants to try it.
No earth-shattering revelations here, not that it matters anyway because I’m 43 and you can only win a Fields Medal if you’re under forty, but this was a fun little diversion.
Update: Minirop pointed out on Twitter that my code wasn’t correctly highlighting the “end” of a chain, which indeed it was not. I’ve poked the code, and the diagrams, to do this better; it’s apparent that both French and German have most numbers end up in a fairy large loop, rather than at one specific number. I don’t think this alters my argument for why this is likely to happen for all numbers (because a loop of numbers which all encode to one another is about as rare as a single number which encodes to itself, I’d guess), but maybe I haven’t thought about it enough!