Is my implementation of happy number OK

[Cecil Westerhof]

Op Friday 1 May 2015 01:52 CEST schreef Dave Angel:

> On 04/30/2015 07:31 PM, Jon Ribbens wrote:
>> On 2015-04-30, Dave Angel <davea at davea.name> wrote:
>>> Finally, I did some testing on Jon Ribben's version. His was
>>> substantially faster for smaller sets, and about the same for
>>> 10*7. So it's likely it'll be slower than yours and mine for
>>> 10**8.
>>
>> You know what they say about assumptions. Actually, my version is
>> six times faster for 10**8 (running under Python 3.4).
>>
>>> But the real reason I didn't like it was it produced a much larger
>>> set of happy_numbers, which could clog memory a lot sooner.  For
>>> 10**7 items, I had 3250 happy members, and 19630 unhappy.  And Jon
>>> had 1418854 happy members.
>>
>> Er, what? You're complaining that mine is less efficient by not
>> producing the wrong output?
>>
>
> It's not intended as a criticism; you solved a different problem.
> The problem Cecil was solving was to determine if a particular
> number is happy. The problem you solved was to make a list of all
> values under a particular limit that are happy.

I can also produce a list. I have the following function for that:
    def happy_number_list(n):
        found = []

        for i in range(1, n + 1):
            if happy_number(i):
                found.append(i)
        return found

But the idea is that if you only want to know if a certain number is
happy or not, it is a waist to determine it for every number.

I have to look at the speed increase to determine if it would be
interesting to make a dedicated version for it.
>
> Both produce identical results for the Cecil purpose, and yours is
> faster if one wants all the values. But if one wants a sampling of
> values, his function will fetch them quickly, and even if you want
> them all, his function will use much less memory.
>
> He keeps only one permutation of each value in the set, for
> substantial savings in space. For example, he might just keep 28,
> while you keep 28 and 82, 208, 280, 802, and 820.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof