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
toStringby 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?" :)
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 simple Rust Solution
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.
The obvious pythonic way:
Jokes aside, here's a Python implementation using simple memoization:
Here is my C# implementation:
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.
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. :)
Can’t resist, here’s a solution in Reason: (Try it)
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'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'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)
Golang Solution
package main import ( "fmt" "strconv" "strings" ) func isHappyNumber(num int) bool { newNum := 0 switch num { case 1: return true case 4: return false default: s := strconv.Itoa(num) digits := strings.Split(s, "") for _, i := range digits { n, _ := strconv.Atoi(i) newNum += n * n } } return isHappyNumber(newNum) } func main() { fmt.Println(isHappyNumber(94)) }F#
Here is a ruby implementation.