The palindromic number conjecture: don't try this! (recreational computing) Michael W. Ecker.

Greetings again everbody! This month--despite the teaser of a title--I have an interesting and intriguing conjecture for you to experiment with. I will also offer a solution to last month's challenge as well.

Let's get started with the palindromic number conjecture. A palindrome in an expression--literal or numerical--which reads the same backwards as forwards, as in "Madam I'm Adam" and 12321. These symmetric symbolisms are of only occasional serious use, but are inherently engaging nonetheless. Indeed, there is even a famous unsolved mathematical conjecture dealing with them. It goes something like this:

Suppose you start with a positive integer. Let's think of 782. Form the reveral of it: 287 in this case. Now add the two numbers: 782 + 287 = 1069. If this number is not a palindrome, then repeat with this number: 1069 + 9601 = 10670. And so on. I'll leave you to continue with that one.

If we start with 48, we have 48 + 84 = 132; 132 + 231 = 363, a palindrome. The question is: Is it true that no matter which number we start with, the process must eventually yield a palindrome?

You will notice that when there are no carries in the addition, as in 132 + 231, it is automatic that the result is a palindrome. Also note that if you experiment with large numbers, the sums that fail to be palindromic generally come close in the sense that symmetrically located digits are usually very close (e.g., 7 and 8). Do you think that a palindrome is inevitable?

This problem has defied an elegant solution, although much is known about specifics using computers. This problem has also been dubbed the "196 problem" since nobody has ever been able to start with 196 in this process and get it to terminate. When I advised you not to try this, I had this in mind. Although I am not very sanguine about the prospects for one of us to make any research breakthroughs, I think you might find it an interesting programming challenge with many possible approaches. Can you write a program to implement the process described abobe? This one could get into precision questions and/or string variables, so I anticipate great variety. If you have a nice solution, please send it to me at the address below.

And Collatz, Too

Another famous conjecture whose solution has evaded solution is the famed Collatz conjecture. I mention it here to give something to do to those of you who may find the first question too involved. It goes like this: Take any positive integer. If even, divide it by 2. If odd, triple and add 1. Repeat. Must you always eventually hit the number 1 in the process? For example, if you start with 15, you get 46, then 23, then 70, followed by these: 35, 106, 53, 160, 80, 40, 20, 10, 5, 16, 8, 4, 2, 1--success. If we continued, we would get 4, 2, 1, 4, 2, 1,... so there is no point in going on. You might enjoy exploring this question further with your own program.

Solution to Self-Listing Program

In June, I challenged you to write a program which, when run, would list itself--without using the LIST command in the program. A person looking at your screen should be unable to tell whether you had just typed LIST or RUN. Here is the solution as provided by Andrew Bulfer and modified by me to work as well as can be expected in Microsoft Basic. See Listing 1.

I should point out that, very strictly speaking, this solution is slightly rigged because Microsoft Basic inserts an additional space in front of numbers. If you have an Apple, the spaces should not be included around the S$ subscripts or in front of the line numbers (the first characters of each string) in Lines 11 to 24.

Time to go again. I invite everybody to try the challenges, come up with your own solutions, and your own problems as well. They should be recreational in nature. Digit delving and other forms of microcomputer mathemagic in Basic are what I have foremost in mind, but I want to hear from you. Your ideas, if used, will be acknowledged in this column. I solicit your new problems, programs, improved solutions, etc. I will also answer readers who have pertinent questions and who supply an SASE (that's self-addressed stamped envelope). You may write to me directly: Dr. Michael W. Ecker, Contributing Editor, Creative Computing, 129 Carol Dr., Clarks Summit, PA 18411.