Welcome to p196.org!
Once you've been slashdotted, you write a FAQ. :-)
I'm a regular reader of Slashdot. On 8/18/02, the p196.org site got listed on Slashdot HERE.
I cannot say in the least that I was surprised by the criticism and comments like "What the hell good is this?", nor was I surprised by some of the incredibly positive comments by some of the posters.
But there seemed to be a lot of the same questions over and over again. (I guess people in general can't be bothered to take the time to read other people's comments, or the entire site, before they spout off.) I got nearly 100 emails, about the site, and most of the people who took the time to write, had positive things to say, or some nugget of information to add to the knowledge base that this site offers. I will get them up as I get time.
This page was never written expecting to be an article of Slashdot. I know that it is scattered. I know that some of it is not entirely clear. I know that there are odds and ends scattered everywhere. But those who find it interesting, will come back and wander around at their leisure, and will absorb what they want to absorb. Anyway, it has forced me to write this page, so that if anything like that happens again, the lazy people of the world will have ONE page to read, before they go and rip off a post to get themselves listed on Slashdot. At least my server held up!! :-)
Ben had replied to someone in the article, Some of the comments below are his.
Does this have any use?
Absolutely none. If you have a use, let us know. Otherwise, it doesn't really have any application. We *have* discovered that iteration of reverse-and-add has fractal nature, does that at least get us a few "coolness" points?
You mentioned a distributed computing project. This won't work, the algorithm has too much serial dependency.
Wrong on two counts. First, the core concept of reverse-and-add *does* yield to parallel implementation (Jason Doucette worked through this one, and has come up with a *really* elegant solution). Second, searching for Lychrels does not involve "deep" iteration of reverse-and-add. It only requires taking a *lot* of numbers to a certain arbitrary depth (10000 digits more than suffices at the starting value range we currently can deal with). So, although deep iteration takes some work to efficiently parallelize, Lychrel searching gives a nearly linear speedup with the CPU count.
Why limit yourselves to base-10?
For the simple answer, all lower bases have trivial proofs of either an infinite number of non-terminating sequences, or no known non-terminating sequences. This makes base-10 the lowest "interesting" base to work in. Of course, the question strikes me as odd... Why not ask why we use base 10 for counting? Why not base 2, or 7, or 60? Just as meaningful of a question.
Does 196 become a palindrome in the other bases?
Yes it does. Matt Emmerton provided the following information:
| Base | Steps Until Palindrome | Total # of Carries | Progression |
| 2 | 1 | 0 | 11000100 + 00100011 = 1110 0111 |
| 3 | 2 | 4 | 21021 + 12012 = 100110 + 011001 = 111111 |
| 4 | 3 | 2 | 03010 + 01030 = 10100 + 00101 = 10201 |
| 4 | 4 | 4 | 1241 + 1421 = 3213 + 3123 = 10340 + 04301 = 20141 + 14102 = 34243 |
| 6 | 4 | 7 | 524 + 425 = 1353 + 3531 = 5324 + 4236 = 4003 + 3004 = 11011 |
| 7 | 1 | 0 | 400 + 004 = 404 |
| 8 | 1 | 0 | 304 + 403 = 707 |
| 9 | 2 | 2 | 237 + 732 = 1070 + 0701 = 1771 |
| 10 | Unsolved | Unsolved | Unsolved |
| 11 | 1 | 0 | 169 + 961 = A1A |
| 12 | 0 | 0 | 141 (initial representation of 196 in base 12 is palindromic) |
| 13 | 0 | 0 | 121 (initial representation of 196 in base 13 is palindromic) |
| 14 | 1 | 0 | 100 + 001 = 101 |
| 15 | 1 | 0 | D1 + 1D = EE |
| 16 | 2 | 2 | C4 + 4C = 110 + 011 = 121 |
| 17 | 2 | 1 | A9 + 9A = 132 + 231 = 363 |
| 18 | 3 | 3 | AG + GA = 198 + 891 = A09 + 90A = 1111 |
NOTE: On 11/14/05, Eric Goldstein pointed out that some of the information above is mistaken. He writes:
Hi Wade,
In a dull moment, I visited your FAQ page and noticed two mistakes:
The answer to the question, Does 196 become a palindrome in the other bases? contains an error in the table for base 12 and 17:
They should be:
12 1 0 144 + 441 = 585
17 2 1 B9 + 9B = 143 + 341 = 484
Cheers,
Eric
What does "Lychrel" Mean?
196 exists as the lowest (base-10) number that does not seem to terminate on iteration of reverse-and-add, but not the only one. Obviously, any consequent of 196 (such as 887) will also never terminate. Other numbers also never terminate, such as 879, and they never converge with the series (known as the thread) generated by earlier numbers either. So, needing a name for these numbers, Wade VanLandingham picked the word "Lychrel" (pronounced la-shrel), and the active 196 community accepted it into common use.
Where does the word "Lychrel" come from?
"Lychrel" was simply a word that was not in the dictionary, not on a Google search, and not in any math sites that I could find. If there is any "hidden meaning" to the word, it would simply be that it is a rough anagram of my girlfriend's name Cheryl. It was a word that hit me while driving and thinking about this. I liked the sound of it, and it stuck. There is no secret to the word. If the name "Walker Numbers" had not been in use already, I would have named them that, in honor of John Walker who did the first million digits.
Since they will not form a palindrome by reversing and adding their digits, are numbers like 295 and 887 also Lychrel Numbers?
Yes.
We have defined a Lychrel number like this:
Any number, which which does not form a palindrome by reversing and adding it's digits repetitively.
The key point being that the numbers 295, 394 or 493 are also called Lychrel numbers, because they will never form a palindrome. To differentiate between the smallest number of a thread, and all others of the same thread, the terms Seed and Kin numbers must be used. These are explained on the Terms and Definitions page.
How can I compare the program I wrote to the one you have, to see which is faster?
For really accurate testing, you can send me your application, and I will compare it to the fastest ones I have. I apologize, but I will not send you Ben's application. (Nor will I send Eric Goldstein's, Eric Sellers' or any others.) Ben or Eric might, but you'd have to ask them directly. Their addresses are listed over and over again throughout this site. Istvan and Ben have both pointed out to me that the differences in efficiently calculating numbers will become more and more apparent with millions of digits, compared to starting at 0. I'll test your app, using one of the larger data sets I have.
As an initial starting point, you can test by yourself, by running your app, and comparing the results to the info posted on the Software Comparisons page. I'll try to get some larger runs up there, to give more comparison points. If I don't get them up, and you need them, write me and remind me.... :-)
For me to do testing, make sure your program uses "Istvan-Standard Formatting", so it will read my files. The format can be found on the File Verification page.
Can I see your source code, to see why it is so much faster than mine?
Yes. (Although it is Ben's source code, not mine.) You can look it it here. Ben has also listed most of the other code that has been generated for the 196 quest. Take a look!!
Why don't you find a proof for this, instead of using a "brute force" method?
If we knew how, we would. If you can find one, please let us know!!!
I couldn't find your name on the site. Who are you?
I am Wade VanLandingham. I am the one who is spending so much of his time in "mathematical masturbation" as one poster put it.