These challenge posts have been a lot of fun. Another one inspired by Fermat's Library.

# Challenge

In the language of your choice, **write a script to find "Happy Numbers."** Via Wikipedia:

A happy number is a number defined by the following process: Starting with any positive integer, replace the number by the sum of the squares of its digits in base-ten, and repeat the process until the number either equals 1 (where it will stay), or it loops endlessly in a cycle that does not include 1. Those numbers for which this process ends in 1 are happy numbers, while those that do not end in 1 are unhappy numbers (or sad numbers).

Looking at the picture in the embedded tweet will probably help solidify the process. Here are the first few happy numbers to help check your work:

1, 7, 10, 13, 19, 23, 28, 31

Have fun!

## Discussion (28)

e: updated to work with all happy numbers

Your code in ES2016+ (and a bit less readable):

You could even shorten the

`toString`

by replacing it with a template string which will do an implicit`toString`

.Looking at your solution it actually fails later in the mix. I was pretty sure you couldn't rely on the numbers not adding up to a single digit happy number (which the only other one beyond 1 is 7.)

1111111 is a happy number which will become 7 after the first iteration and 7 is a happy number. This fails your current function. Here is an updated one that would work by testing if these ever hit 4 instead of length of 1.

Hmmm, good catch :D Although the fact you found all the sad numbers end in 4 is even more interesting to me.🤔🤔

I read the wikipedia article cause I was like "wait if it's not happy wouldn't that go in to an infinite loop?" :)

The number 42 is also in that loop, by the way. :)

Here is a nice solution in JavaScript:

Then you can play with generators for instance:

Another quick PHP one. Betting there is a more performant method but will leave that to someone else. :)

How does this look? I initially had happy memoizing previous numbers, but it seemed like it ran fast enough without it, and the memoizing cluttered things up.

Also, I didn't know about the digits method until now! :)

Adding a solution in Haskell:

Note that Haskell function composition with the (.) operator is read from right to left (or from bottom to top, respectively). The hardest part for FP is folding with a non-trivial break condition, here.

Here is my solution, to keep me fresh in haskell (I rarely have the possibility to use it in projects and thus never learned it properly):

I'm glad to see some Haskell here. :) I somehow prefer your computational approach to split the number over my quick string hack. You can easily change the base.

I have done a lot of parsing stuff in Haskell with parsec, attoparsec and readP, lately. So I instantly think of parsing when I see the problem of splitting a number into digits. The detour via strings is comfortable,

~~because it uses the read parser.~~but"Challenge" accepted to solve it computationally. :)

To import as few / basic libraries as reasonably achievable, I decided not to use the parsec library but to write a homemade digit parser.

What you do in splitNum reminds me of the quotRem function (that I found when I coded for the Challenge about Kaprekar numbers, here). quotRem just needs a swap to make for a nice digit parser in a very organic way: When dividing by 10 the integer quotient is the state of the state monad (that's still to parse) and the remainder is a parsed digit.

I am a bit biased to use (faster) Ints in my prototypes, and use Integers where really needed, but I adopt your approach with Integers by at least generalizing the code to Integral types.

Although I learned to prefer folds over homemade recursion, I'm afraid the abstractness of foldP is a little bit hard to read, so perhaps I stick with the homemade recursion, this time. :)

And now that I have learned a simpler break condition for the problem, it is easier:

On the other hand, I like the possibility of my original code to see the list of intermediate results to get a feeling for the problem.

Here's my previously golfed version in perl6 made slightly more readable. Includes a state based cache to reduce recursion. The final line prints the happy numbers up to 200 (well up to the last befor 200)

Can’t resist, here’s a solution in Reason: (Try it)

Here's a golang implementation, optimized for speed. It takes about 200ms on my machine to find all the happy numbers from 1 to a million on my machine if you take out the prints.

Here is my C# implementation:

F#

Elm solution which does not use strings. Hopefully quite understandable.

Two recursive functions. Exit conditions are getting a number between 0 and 9. Zero is impossible to actually get from other numbers, but there if someone input 0. The only happy numbers in that range are 1 and 7. Should work with negative numbers too.

Here is a runnable solution with UI to test a range of numbers. Try it at elm-lang.org/try.

A simple Rust Solution

The obvious pythonic way:

Jokes aside, here's a Python implementation using simple memoization:

A work in two parts. First, Happy.pm, a Perl5 Module.

Which is called by a program.

Not particularly golfy, because I like reading and understanding things.

Here's mine in C#. I feel like this could have been way shorter though. Oh well :p

bro log code is not good......

Thanks for letting me know.

What should I change so that my code improves?

Golang Solution

Here is a ruby implementation.