6 kyu
Simple sum of pairs
29 of 1,007KenKamau
Loading description...
Fundamentals
Performance
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Quite tricky challenge to solve, congratulations.
very fun kata! :)
For C, if n is a + b and both a and b are non-negative, then why does the function pass in a signed value (and why is it "const")? That needless complictes this clever problem.
finally solved...cant believe it! after expeding some time a day trying to optimice. Learnt a lot :3
in c++ input parameter has type long, but 10e10 numbers can't fit into long, maybe change to long long?
You are probably solving on 64-bit Windows where
long
is 32-bit. Codewars runs on 64-bit Linux wherelong
is 64-bit. As a quickfix, you can uselong long
in your solution. But I agree, this is an issue, C/C++ code on Codewars should never uselong
as it makes the user experience worse for Windows users.I agree, the types used in a kata should not depend on one particular compiler implementation. In particular, if you need an integer type that must hold values larger than what fits in 32 bit, it would be better to use one of the fixed-width integer types from cstdint, e.g. int64_t.
This kata is SOO GOOD!
I've spent a whole day figuring out how to optimize the code, since it timed-out at random tests. It made me go through the rabbit hole of finding out how the summation of digits works and how to MAX the result and minimize the number of iterations.
Honestly, this mixture of frustration and EUREKA! is what I'm looking for.
very fun and interesting
I belive that the tests digits are unreasonably large. After trying to optimize the code, it just can't execute in time
same problem
that's the whole point of the kata. unfortunately the kata is underranked, but at least now there is a
performance
tag to warn you. you need to find a better algorithm.I solved this kata 4 fours ago. There is no any problem with test digits.
Thanks for the help and confirmation!
Super kata!!! :') I'm too focused with only 1 + 4 + 1 + 5, which you can do with 999....
I think the tests involve digits too large for Codewars' servers (perhaps the maximum time permitted has reduced since this was made). No matter how I write it, it always times out.
Man, I started facing the same issue... that's really sad that I can't complete this.
Solutions are tested up to 10^10. Obviously, naive solutions will time out.
There's no need in any brute forсe. Solution has complexity o(1).
python new test framework is required. updated in this fork
Approved
should have
performance
tag as the naive solution times outAdded.
C#: method name should be
PascalCase
(Please refer to implementation of backward compatibility here )I don't understand:
not 24 !!!!
Namely 33 <<<
This comment has been hidden.
This comment has been hidden.
I cant believe I solved this. This is actually easy... Very nice kata. Interesting ways to solve..
Good day, guys) Could you provide any hints to speed up the execution time?)
I dont know about hints, but try to use less loops... There's an easy solusion. Just need to play a bit with numbers to get it.
Good one !
COBOL translation.
looks good to me
Approved
Top notch kata !!!
I am really wondering how you find those Kata ideas!
During the first minutes, it seems obscure and difficult and then ... a magic formula appears!
Very satisfying Kata!
This comment has been hidden.
29==15+14 sum of digits = 1+5+1+4=11 29==19+10 sum of digits = 1+9+1+0=11 29==29+0 sum of digits = 2+9=11 which solution is correct?
You have to return 11, it doesn't matter which a and b you used.
Why attempting takes more than a twice of the time rather than actual testing?!...
because when "Attempting" it runs with a bigger test input and eventually you will get timeout if your alg is not optimized
This comment has been hidden.
Please post as question.
could you add to the sample tests this case: Expected: 144, instead got: 99 My solution is passing all the sample tests, but I have several problems when going to Attempt.
That's a random test, read this. Print the input.
Can someone please tell me what this means? C) DigitSum(a) + Digitsum(b) is maximum of all possibilities. a.i. what possibilities are you referring to? It's too vague for my current understanding.
DigitSum(a) is sum of digits of the number (a).
In the example given, solve(29), there are many ways to get 29. One is 15+14. Another is 16 +13, and many other possibilities. The possibility that has the maximum sum of digits is 15+14.
This comment has been hidden.
This comment has been hidden.
Brute force may not work. The reason it's 6 Kyu is that performance is not a requirement.
Hello!
I´m finding some trouble trying this kata with both C# and Java, specifically when testing the last two cases (with Long Integers), it throws this exception (speaking about Java now):
"./src/test/java/SolutionTest.java:14: error: integer number too large assertEquals(144,Solution.solve(15569047737)); ^ ./src/test/java/SolutionTest.java:15: error: integer number too large assertEquals(116,Solution.solve(2452148459));".
Is there any way of adding an "L" to the end of the input Long Integer?
Thank you very much in advance and kind regards.
Please refresh and try again. I've removed those from fixed tests. Random tests should be OK.
Hello again!
Thank you very much for your quick answer.
As you suggest, when I "Submit" my code the "Random Tests" appear as "Passed", but the "Basic Tests" throw an exception like this:
"For input string: "" Stack Trace java.lang.NumberFormatException: For input string: "" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.base/java.lang.Long.parseLong(Long.java:702) at java.base/java.lang.Long.parseLong(Long.java:817) at Solution.solve(Solution.java:19) at SolutionTest.basicTests(SolutionTest.java:8) ..."
Is there something that I could be missing when trying my code?
Again, thank you very much in advance and kind regards.
See here to check what input makes your solution fail, and try to recreate this test case locally. If it fails also on your machine, you know it's not the kata problem and what to fix.
Hello again!
Everything works just fine, I did as suggested and it eventually worked.
Thanks again!
I don't understand this question, there is just one exsample. can someone write how the code should work for the number 7019: how did the got to 35? and why?
It could be like this:
for 7019 a = 1020 b = 5999 so that a + b = 7019 and digitsum for a = 3, b = 32 therefore result is 35.
My first working attempt led me to the vicious timeout error :). I had fun optimizing the solution.
C translation kumited
please scrutinize for approval
Approved. thanks.
[Haskell, possibly others]
choose (0,10^10)
will almost exclusively generate huge numbers. May I suggestdo { e <- choose (1,10) ; choose (0,10^e) }
?Fixed in all languages.
[Haskell, maybe others?]
Why
:: Integer -> Int
?Int
s are 64-bit;10e10
will fit comfortably.Int is the result and is a much smaller number than the input.
I meant it can be
:: Int -> Int
.Fixed, changed to
: Int -> Int
.Needs edge case of 1 digit number, and
0
.Test cases updated.
Resolved!
1e11
or10^11
.10e11
would be1e12
..Max is
100000000000
.Looks like 10e10. Updated.
;-)
Fixed already. Please refresh.