4 kyu
Almost Everywhere Zero
Loading description...
Algorithms
Logic
Mathematics
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.
Great technical kata.
DP, combinatorics, numbers... I almost lost my mind (#.#) It's a real olympiad challenge!
I had forgotten most of the stats I had learnt. This kyu really made me have to try and remember everything. Great Kyu! Learnt alot.
Hi everyone! I'm having an issue with handling big numbers in Codewars. For example, in this Kata for (almost_everywhere_zero(10000000000000000000000,21) I get 2.407217760893272e+21 instead of 2407217760893271902598.
I've tried to get rid of scientific notation using int (number), but the answer ends up being rounding incorrectly: 2407217760893272064000.
I do get the right answer using exactly the same code on my laptop (Python 3.8), so I think there's some issue with handling big numbers in previos versions of Python, but I might be wrong.
I will appreciate any suggestions!
you're actually not supposd to use divisions here. I mean, doing so, I strongly doubt your solution will be able to pass the full test suite (talking about performances).
Or maybe for one tiny thing, yes... in any case, use
//, not/This comment has been hidden.
won't be enough, by f...ing far... ;) (you're supposed to handle numbers with like 100 digits!)
This comment has been hidden.
example you provided works completely fine with me
... :o wut!??
There are no such things in python since 3.0
integers have infinite precision at whatever scale you want, to the very only condition that you don't apply any floating operation to them. So it's there, somewhere in your code: you're using the wrong kind of operation/operator/function somewhere.
Could I possibly post my code here and mark it as a spoiler? I really don't understand why it works totally fine on my laptop, but fails when I submit it.
yup, you can. Don't forget the markdowns...
This comment has been hidden.
ok, I guess the problem is that you rely on the library and you don't control what's done in there. Just implement that on your own and you'll be done with it.
note: markdowns...
Yes, that was the problem. Thanks a lot for your help!
This comment has been hidden.
2604 is correct
Can you add the following test case to the sample test suit:
Test.assert_equals(almost_everywhere_zero(1203,4), 81)
This one solved my edge case :)
done
Is it possible that some tests where k>90 are wrong?
no all tests are fine
I can confirm all tests are correct! Very interesting edge case though.
Is there a possibility that there are rounding problems if my algorithm only fails with very large numbers? (The testing phase is passed, but several problems occurs during the attempt)
I have the same problem, 100/106 tests pass, and I'm fairly certain I'm doing things correctly, only if k > 90 some tests fail and I have a straight forward mathematical solution...
Same. It'd be helpful to see the inputs.
you can always print the inputs, but not sure if it will help, n is so huge you won't be able to check it by hand...
Hi guys, did you figure out the reason why your algorithm could not handle very large numbers?? I am getting the same errors when k > 90.
This comment has been hidden.
Maybe I didn't learn enough. I used the for loop to traverse all possibilities. But the data of n = 10 ^ 22 is way too large, and it will time out. Can you give me some hint on this kata?
There is a pattern that I've found which correlates to values in Pascal's Triangle. This has led me to a solution that passes all but a couple random tests that I'm convinced are wrong 😅
Pascal Triangle principle works for the solution. ı used the same way. if u didnt find out the solution. please dont hesitate to ask !
I tried Pascal Triangle principle and it works fine.But here comes a new problem with those huge numbers.I'm certain that the problem have something to do with numerical precision.
you need more fixed tests, exploring some specific situations (because the random tests may never generate those):
could be good to have those in the sample tests too (or at least a sample test with k=3)
Thank I will put it more
why only 3 digits? My solution could handle any number...
Ok I will Increase
Can you tell me the data structures/programming techniques needed to create such an algorithm.
Nice. But you should push the number of big tests way higher than this, I believe
I will Do it
Thank for suggestion