Is my implementation of happy number OK

Dave Angel davea at davea.name
Thu Apr 30 19:52:13 EDT 2015


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.

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.


-- 
DaveA



More information about the Python-list mailing list