Welcome to p196.org!
Origin: Important comments taken from an email dated 1/19/03 from Vincent to Wade. I have deleted what I feel were "personal" or update comments. What is left is the very heart of his message.
Our conclusions were:
a.. 196 will probably never lead to a palindrom. The mathematical property to prove this assertion is to find cycles in digit sequences that may occur (this work has been done in binary basis and should be extended to decimal basis: that's one of the two only ways to prove it - see below).
b.. You can obtain palindroms even with carries (take 29 for instance). This kind of numbers are referenced as 'lucky numbers' in our paper. But your link in this page to K. Brown's work is surely one of the most relevant among the profusion of Web litterature about this topic...
c.. in the process of computing numbers that can't lead to a palindrom, a lot of operations are irrelevant. When you compute 196+691, you also compute 295+592, 394+493, and more generaly 2 x [ (7/2)9(7/2) ], where 7/2 should be considered as a (pseudo-)digit. That is to say, 196, 295, 394, ... all belong to the 'class' of the pseudo-palindrom 7/2 9 7/2 (where 7=1+6, 2+5, 3+4). We characterized these 'kins numbers' without any trouble in our article for any basis. I saw on your web pages that you call them 'Lychrel numbers' for the decimal basis. Please update your ethymology/history: they were called 'kins numbers' by a Japanese mathematician K. Yamashita (see http://www.jams.or.jp/mj/45-1.html for references) in 1997, and we, together with Sébastien Veigneau, gave the right math definitions in 1998 - published in 2001 :-(
d.. starting from these results, in '7/2 9 7/2', there is an obvious duplicated information: we can work only on 7/2 and 9 digits to see mathematical properties of this number (196). This process can also be recursively iterated, so we wrote a recursive maple program that computes the sum of a number and its reversal (see http://phalanstere.univ-mlv.fr/~vince/MAIN/palindrom.html)
e.. We also characterised math properties that allow one to forecast if a number can yield a palindrom, and how many computations it will take to do this...
So, what's going on? The web litterature about this problem is a bit confused, and as your web site is certainly the most complete, I think you should make it more comprehensible and accurate: on one hand, you have computer scientists that attempt to obtain a palindrom from 196, on the other hand, there are a few mathematicians that gave right hints to discover it will never be possible. I belong to both groups, but I am fully convinced that the latters are right (since this problem is not related to the decimal basis, but to a deeper math property about cycles in digit sequences that propagate during the process of iteration).
The work that has to be done to conclude this topic is either:
a.. following K Brown, identify cycles for differents basis (3,4,5,6... up to 10) and you'll get the right result (this may take some times...). The page http://184.108.40.206/webs/math/mathpages/www.seanet.com/~ksbrown/kmath312.htm is of particular interest.
b.. identify math properties (obviously recursive ones) as we did, and try to find out what is the right property in the recursion process We left this last issue unachieved, since it wasn't of major interest for us (at this time, we had more research work to do, and now I don't work on this topic anymore), but it can't be a dead investigation...
The math solution is either an extension of K. Brown's results or Prosper/Veigneau's ones, and probably a mix of both. That is not to say that we are proud of our work: this is simply, mathematically speaking, the only two solutions: the first one attempts to exhibit a witness cycle in the 196 process, the other one tries to recursively qualify a math property (that has to be found in the recursion) that definitely proves that the algorithms loops. A very good work could consist of merging Brown's and our works for the binary basis: just try to identify the binary sequence given by Brown in our recursive algorithm and you'll be done for binary numbers. Extending it to decimal numbers will probably be immediate and the endless loop for 196 will be definitely proven. As I understand that our paper is not really easy to understand for non-mathematician, another computer solution tip is to apply Brown's considerations to the huge numbers you already computed and saved. That is to say : try to find such 'pyramids of numbers' (as described in his pages) in your result files.
In my opinion, trying to find properties in decimal basis without taking into account that the solution will be generic for any basis is not the right approach and will obviously lead to false assumptions.
Have a nice day.