6 kyu
ATM Heist
31 of 63Firefly2002
Loading description...
Algorithms
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.
I tried to run two Ruby solutions in Python and they both timed out o_O I guess this is un-Python-translatable?
It's that old issue again probably, random number generation is very slow inside container for some reasons.
No reason this shouldn't work just fine in Python, works in Ruby, although in my experience Ruby (at least on CW) outperforms Python on array iterating (my Ruby tests here basically match the JS tests).. maybe just tone down the tests.
https://github.com/Codewars/codewars-runner-cli/issues/757 I guess
Oh. Well that's kinda sad :/
Anything besides random number generation that's slow in this kata? Has anyone tested reading from
/dev/urandomas a workaround?Haskell translation
Hey, Johan :)
Thanks for the translation.. would you mind adding in the edge cases (referenced below per Voile's point)? I added these after your translation, sorry about that. Basically just ensure for a few tests that the ideal choice is choosing the same ATM twice. Don't care if you mirror it the way I did exactly or not.
Cheers :)
I've added the
[3,1,6]case from JavaScript. ( Ruby doesn't have that yet, is that correct? )Will that do?
I added the 3,1,6 in sample tests and didn't bother including it in the full test suite since I also implemented random tests ensuring it happened, but sure, I mean I don't really care too much, as long as no on else has an issue with it. Approved.
Ruby reference solution is wrong:
The result should be
449 + 433 + 2=884.JS reference solution is also wrong:
400 + 448 + 2=870Okay never mind, the same index can be chosen twice.
Then the issue is, there are no fixed tests to catch this specific edge case and it only appears very sporadicatlly in the random tests. My previous solution that didn't handle this correctly still passes after a few submits.
Ah, there's a point. Edge cases added.
Probably because in your reference solution you use
-InfinityOr because
max() == -Infinity?one of the sample tests in ruby calls for the JS method. ;)
Lol, fixed
May not have checked it over quite thoroughly enough after translating 😇
missing edge case:
[0]done
seems there is a problem with the code blocks. ;) (you need empty lines before/after them, unless the stuff above/below is another code block)
Lol I hate you. It's literally been 30 seconds since I published, and I was in the middle of fixing this when I saw your comment 😂
x)
:)