Talk:Happy number

From Wikipedia, the free encyclopedia

I removed the text:

It can be shown mathematically that no matter what the initial number t is, the sequence t0,t1,t2,.. will eventually settle between 1 and 163. What happens to this sequence after it is inside this interval can be estimated by a simple computation.
It turns out that the only alternative to ending up at 1 is to be stuck in the cycle
4, 16, 37, 58, 89, 145, 42, 20, 4, ...

as I couldn't find these claims in either reference, and I strongly doubt they've been proved. dbenbenn | talk 21:23, 28 Jan 2005 (UTC)

The second part is in the references. The first one I proved. I did not know on Wikpedia you must submit the proofs. What is a good way of proceeding about that? Assuming that the text fragment is accurate, and since it adds value to the article, maybe it should be left. What do you think? Oleg Alexandrov | talk 21:39, 28 Jan 2005 (UTC)
I should have given you more time to explain yourself. :) I got your message. I think, in the fragment above I said that it can be proved that things will settle between 1 to 163, and only from there on one can do some computerized checking. So, you want me to include the proof? It is not that hard.
Which reference do these facts appear in? Note that the second claim implies the first. I agree that if you can show any number eventually goes below 163, then it's simply a matter of checking those cases. dbenbenn | talk 21:48, 28 Jan 2005 (UTC)
OK, I made a mistake. In those references it was mentioned only that we either are in the cycle 4, 16, .... 4, or otherwise end up at 1.
You are right, it was not mentioned that you get stuck in 1 to 163, and what happens next.
So, I can prove that you get stuck in 1 to 163, and I had written a code to show what happens next, but that one was voted for deletion (which I think was appropriate).
So, we have 2 options. (a) Keep things the way they are now. (b) Put back the statement with the proof. What to do about the "fact" of what happens after you are between 1 to 163 I don't know. That can be checked only computationally.
Suggestions welcome. Oleg Alexandrov | talk 21:54, 28 Jan 2005 (UTC)
Are you referring to the MathWorld article? It says
"Unhappy numbers have eventually periodic sequences ... which do not reach 1 (e.g., 4, 16, 37, 58, 89, 145, 42, 20, 4, ...)."
E.g. means for example. The article does not say that unhappy numbers always end up in the 4, 16, ... cycle.
If you have a proof of this fact, I suggest that you should publish it. You're a postdoc, you need to publish papers! And once it's been peer reviewed, we can refer to it here no problem.
Additionally, I invite you to write your proof here on this talk page. I would be interested in seeing it. But I don't think it would be appropriate to include in the article until it's been peer reviewed. dbenbenn | talk 22:06, 28 Jan 2005 (UTC)
Got it! I did not know you guys are so strict about things, but that makes sense. So, let's drop it.
About the proof. The idea is quite simple. If you start with a large number, and sum the squares of its digits, then, as you might guess, what you get is much smaller than the original. If you do it several times, you keep on getting much smaller number each time, until you are between 1 and 1000. From there on, a bit more care is needed with calculations (but is still simple) to see how much further you can drop. For example, for 999 you end up after one step with 81+81+81 obviously, which is 243. From the range 1-243 the number with the largest sum of squares of digits is 199, for which you get 1+81+81=163. And from here on, a little program can check where you end up after several iterations.
This could make a nice math competition problem. But I agree with you, not worth the trouble puttin on Wikipedia. Oleg Alexandrov | talk 23:07, 28 Jan 2005 (UTC)

Er, um, let me back-pedal please. I hadn't actually thought about this sequence at all when I wrote the above. I had just assumed that things were difficult. Now having thought about it for a few minutes, I agree it's quite simple. Any number above 999 goes to a number with fewer digits, so you eventually get to something 999 or below. Then it's just a matter of checking. This level of reasoning can certainly go in the article. I'll start adding it right now. dbenbenn | talk 23:18, 28 Jan 2005 (UTC)

Done. For what it's worth, it was never about strictness. The problem was simply that no justification for the claims at the top of this thread were given. dbenbenn | talk 23:54, 28 Jan 2005 (UTC)

There is a problem with proof. You see, you focus too much on what happens over 100. If you are at 99, you jump up to 162. And then, if you drop below 100 again with your reasoning, you can come back later. So it is not clear if you ever get stuck under 100. So I think you should say we are stuck between 1 and 162 and leave it that way. What do you think?Oleg Alexandrov | talk 05:44, 29 Jan 2005 (UTC)
I disagree. The computer program proves (presumably; I haven't actually checked it) that every number 1 to 99 is either happy or goes to 4. And every number above 99 eventually goes into the range 1–99. So (I think) the proof as I modified it is still correct.
The interesting fact, which I was trying to get at in my edits, is that 99 is the last number that gets bigger, which is why it's "special" with respect to this process. 162 isn't special in that sense. If you're going to stop at 162, I think you might as well stop at 1000. But the extra analysis to get down to 99 reveals some interesting structure in the sequences. dbenbenn | talk 06:24, 29 Jan 2005 (UTC)
If you put it that way you are right. And emphasizing 99 is good too. What I got confused about was the following: I would have really liked to not even talk about what happens under 163 (over 100 versus under 100), as there things jump around quite a bit. For comparison, while once we are in 1 to 163, we are dead stuck there. Your proof was not wrong, I misread it expecting something else. Oleg Alexandrov | talk 16:36, 29 Jan 2005 (UTC)

Contents

[edit] Checking up to 163

The following program by User:Oleg Alexandrov can be used to check the claim in the article about 1 to 163:

% Find the happy numbers, and the cycles which do not lead to happy numbers.
% Assume that we start at some integer between 1 and 163.
% It can be proved that the sequence t_0, t_1, ... as in the article,
% always stabilizes in this interval.

function main(m)

   A=zeros(163, 20); % row i will store the cyclical sequence starting at i
   
   for i=1:163
      N=i; % current term
      for j=1:20 % can prove that at most 18 iterations are necessary to start repeating the cycle
         A(i, j)=N;
         N=sum_digits(N);
      end
      
      if  (N ~= 1 & N ~= 4  & N~= 16  & N ~=  37 & N ~=    58 & N ~=    89 & N ~=   145   & N ~=  42   & N ~=  20   & N ~=   4)
         disp('We have a problem! We neither got a happy number nor are we');
         disp('in the cycle 4    16    37    58    89   145    42    20     4 ');
      end
   end

   
   A(1:163, 1:20) % display a table showing in each row the with all the cycles (please ignore the trailing zeros)

function sum=sum_digits(m)

   sum=0;
   p=floor(log(m)/log(10)+0.1)+1; % number of digits
   for i=1:p
      d=rem(m, 10);
      sum=sum+d^2;
      m=(m-d)/10;
   end

Dear dbenbenn, I took so much of your time. I am flattered. Thanks. Oleg Alexandrov | talk 00:45, 29 Jan 2005 (UTC)

That's what Wikipedia's all about. Thanks for explaining it to me, and I'm sorry I misunderstood at first. dbenbenn | talk 03:17, 29 Jan 2005 (UTC)

[edit] Checking up to "anywhere"

The following tiny C program checks up to "any" number (< MAXINT), which can be given as optional argument (default=99), to see that no number gives an infinite loop, but always ends up at 1 (happy) or 4 (unhappy)).

It prints a message "xxx is (un)happy" for each number, unless an additional second argument is given (e.g. "silent"), in which case only the currently checked number is displayed (without linefeed).

In view of the highly non-optimized code (KISS principle), it takes about 20 sec on my PC to check up to 107 (ten million) (but maybe most time is spent in printf calls).

/* happy.c */

 sum(int i){ /* (recursively) calculate sum of squares of digits */
  return(( i<10 ) ? i*i : sum( i/10 ) + sum( i % 10 ));
 }

 happy(int i){ /* count iterations needed to reach 1 or 4 */
  int c=1;
  for ( ; i > 1; c++ ) if ( i==4 ) return( -c ); else i = sum(i);
  return( c );
 }

 main(int c,char**v){
  int i, h, max = ( c>1 ? atoi( v[1] ) : 99);
  for( i=1; i<=max; i++ ){
   printf( "%15d\r", i); h = happy(i);
   if( c<3 ) printf( "\t\t is found to be %s after %d iterations.\n",
               (h>0 ? "happy":"unhappy"), abs(h)-1 );
  }
 }

Enjoy... — MFH 23:34, 9 Mar 2005 (UTC)

[edit] A thought about proofs using computers

The proof on the main page has some quite developed (and interesting) reasoning concerning numbers below 1000, and terminates by "a computer program can easily verify that in the range 1 to 99...". Now,

  • first, the computer program checks as easily (in less than a millisecond) up to 999, thus making the longest part of the proof superfluous. (Understand me well, I find this part nevertheless most interesting!)
  • secondly, it cannot be checked by reading the proof whether this statement (about 1..99) is true or false. In order to have a "complete" proof, one would need the explicit list of the sequences for the remaining numbers (where the sequences could be truncated whenever a number less than the "starting point" is attained).

Of course, for the latter (explicitly displayed list) the difference between 99 and 999 is crucial. Thus, in some sense, the "lack" or "necessity" of what is missing in the end (in order to have a complete proof) justifies what is (without it) "superfluous" at the beginning. Quite remarkable! — MFH: Talk 17:20, 29 September 2005 (UTC)

[edit] unhappy 42

I made a program that prints the sequences obtained for the numbers 1..99, but only up to the point where a number less than its predecessor is obtained (i.e. the point from which on the sequence is no more increasing). I noticed that most often this point was the number 42. More precisely, I counted for each number how many times it plays the role of such a "breakpoint" (for 1..99). Here are the results:

   1: 5.    2: 1.    4: 1.    5: 2.    8: 1.    9: 1.   10: 7.   11: 2.   13: 2.   16: 3.   17: 1.
  18: 1.   20: 2.   25: 5.   26: 1.   29: 2.   32: 1.   34: 3.   36: 1.   37: 4.   40: 1.   41: 5.
 42: 14.   45: 1.   49: 1.   50: 2.   51: 2.   52: 2.   53: 2.   58: 2.   61: 3.   64: 2.   65: 5.
  68: 2.   69: 1.   73: 1.   74: 1.   80: 1.   81: 2.   82: 1.   85: 1.   90: 1.    All others: 0.

I.e., while 42 is the breakpoint for 14 numbers, all other numbers are breakpoints for at most 7 numbers.

Of course this result is related to the choice of the first 100 numbers, but I don't think this is very important. (In fact, 42 remains the favourite taking into account all numbers up to 999, but the distribution becomes more homogenious for the others.) Strange, this 42.... — MFH: Talk 22:21, 29 September 2005 (UTC)

It's the meaning of life :-) --HappyCamper 02:42, 5 November 2005 (UTC)

[edit] History?

So who first defined happy numbers? How did they come up with the name? What significance (if any) has the research of happy numbers had?--AlexSpurling 20:21, 5 October 2006 (UTC)

According to Unsolved problems in Nymber Theory by Richard Guy, Reg. Allenby's daughter thought of them. They have little significance, just are interesting. Bubba73 (talk), 21:05, 5 October 2006 (UTC)
Can you add that to the article, with the reference? (I don't have the book) That's an interesting tidbit. - DavidWBrooks 15:09, 6 October 2006 (UTC)
done. I wish I knew her actual name though. Bubba73 (talk), 15:25, 6 October 2006 (UTC)

[edit] unhappy 23

23 is NOT happy: 23²=529
5²+2²+9²=110
1²+1²+0²=2
2²=4
4²=16
1²+6²=37
3²+7²=58
5²+8²=89
8²+9²=145
1²+4²+5²=42
4²+2²=20
2²+0²=4
 Please feedback if i'm wrong or not!!! wiki@dbserver.nu (March 30, 2007)

Wrong. 23 -> 2²+3² = 13, not 23². Sum of the square of the digits. Bubba73 (talk), 14:54, 30 March 2007 (UTC)
Sorry!
Retrieved from "http://en.wikipedia.org../../../h/a/p/Talk%7EHappy_number_c9ed.html"