These challenge posts have been a lot of fun. Another one inspired by Fermat's Library.
// Detect dark theme
var iframe = document.getElem...
For further actions, you may consider blocking this person and/or reporting abuse
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! :)
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 implicittoString
.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. :)
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.
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.
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?
your feedback...
your code write is good and logic is also good , but you code very long ,,,
so, listen ,try to write code small, simpal
Here is my C# implementation:
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)
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:
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.
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. :)
F#
Golang Solution
Here is a ruby implementation.