6 kyu
Jumping down the staircase
103 of 214Konstantin Modin
Loading description...
Dynamic Programming
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.
Fix for Rust, anybody approve: https://www.codewars.com/kumite/65c914a14e43b27b6c426d57
done
well darn, I just authored and published my own fix before seeing this.
Note: I chose
BigUint
everywhere. I also refactored the tests and made better assertions, so mine is now the official version, sorry :)description still mentions this ..
Because
BigInt
is clear enough as a general type, and some languages don't even have the concept of unsigned numbers. I see no reason to make this language specific if the exact type is clear from the signature.Rust: The sample tests use BigUint, but on submit, BigInt is expected.
See comments below of user complaining about it.
fixed above
I'm thinking the Rust version may be broken:
When I add
use num::BigInt
, I get this error instead:It doesn't matter what I write inside the function; these compilation errors always occur.
The sample tests use BigUint, but on submit, BigInt is expected. I'll log an issue.
Great kata! Rust translation: https://www.codewars.com/kumite/64ff82c4546022004bcfb6eb
I'm wondering if this Rust translation is broken? Hopefully I'm missing something. See my comment above.
yes it was broken, and now fixed
Nice kata, Konstantin!
Took me longer than I originally thought, but was quite interesting and led to think about different approaches to tackle it. Hope to see a few translations. For the record, I didn't have any issues with the description or implementation, with the exception of using BigInt all along.
Thank you!
Python translation: https://www.codewars.com/kumite/64808c6e8301d30051640310?sel=64808c6e8301d30051640310
Approved
Function/parameters names seem a bit confusing
getStepsAmount
returns a number of ways, not a number of stepslength
is a number of steps, and can be greater thanmaxStepsAmount
Other possible names:
numberOfWays(totalLength, maxJumpLength)
,numberOfWays(steps, maxJump)
Maybe a native english speaker can suggest better names.
Thank you, good catch. Updated namings.
Rounding problems?
exact value:
9671402305519268090871688
exact value:
39614081257132163299213836288
JS should use
BigInt
instead of normal numbers.I also was afraid of it, now iplemented it wit BigInt as @Voile suggested. Thanks for your help!
Issue resolved
And I added hard-coded test cases just for your examples as well.
Input size should be specified.
Thank you, updated description.
you can republish your kata now
This is just integer partition with a maximum limit for each item. There are a lot of integer partition katas already...
You usually make an "issue" for this. You think this kata differs enough from existing kata's?
They're not exact, so not really an issue. Besides all the existing katas require unique combinations (which is a bit different), and without maximum limit for each part (relatively trivial difference).
This comment has been hidden.
Then we'd better keep an eye out for dups, and raise an issue if necessary. For now, it seems to be OK.
If you want performance criteria, you should go for higher values (times 100 of current tests) of length and steps. Also, your current reference solution will not be able to deal with it.
Using my solution:
Time: 5258ms Passed: 300Failed: 0
Perhaps there are even faster solutions ...
Thanks, removed performance tag.