Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Really enjoyed this, but I think the instructions should clarify the following:
I was ashamed of the hard-coding in my first solution, so I came back and changed my medved function to iterate over (and test) all possibilities.
Fair enough. Sounds like it would have been good to present the idea in the Discord discussion before creating the kata.
I liked it. This is definitely a situation where I would usually try to convert to string first, so I had to think differently. I didn't even try to get around the restrictions, but went along with the spirit of the kata. Thanks for the challenge!
(If people are going to downvote this kata, it would be helpful if they'd at least come on here and tell us why. Is it a duplicate? Is it too easy? Are the restrictions too easy to circumvent?) Help the kata author by providing some feedback.
This "solution" is horrendous. The approach I was originally taking only worked for n values up through about 170. So I thought that for higher values, I could possibly call the next-lower n value recursively and then apply a kind of reducing factor to its result. While I tried to fine-tune that factor, I gradually added more and more hard-coding. It's an ugly mess.
Thanks for the clarification!
What exactly constitutes moving "away from" an enemy? This needs to be defined more precisely. For example: If an enemy is in position to attack me (i.e., above, below, left, or right of me), and I move to a new position, so that this enemy is no longer above/below/left/right of me, can that enemy still attack me?
This made me think hard about how to avoid my usual slow brute-force frontal assault. I got oh-so-close with a few different approaches, and then finally shocked myself with a one-liner. That never happens! Thanks for the fun challenge!
Thanks for the fun kata. Brings back memories of looking at hex dumps of RPG programs and wondering what in the world they meant.
The description isn't clear. I needed to study the example pretty carefully to figure out what needed to be done. For one thing, it should be clarified that the prime divisor is never added to the element at index 0, despite the fact that 0 % [prime] equals 0.
Here's an example of input whose expected output does not follow the "one vowel per line" rule:
"oGweQFMoJNk KnJLHOtimUtRTu GirCkKZBLIzXtOfTfNvfI h"
If the test conformed to the description, the last line of expected output would be "fTfNvfI h". But the expected output instead puts a newline after the I and leaves h on the last line by itself.
In testing and modifying my code to handle cases like this, I found that it was the space following the I that was triggering the newline. If that space were not there, the last line of the expected output would be "fTfNvfIh". This is not explained in the description.
You should really not mark issues as "Resolved" until they have been resolved. I think you first need to reach a clear understanding in your own mind about the rules for the expected output. Then these rules will be easier to express accurately in the description.
OK, but I saw at least one case where the test did require a new line after the final vowel if there was a space after that final vowel. That should be explained.
Danke gleichfalls!
The description states: "The final result should have exactly one vowel per line." This is clearly not the case in the expected results for many of the tests.
This comment is hidden because it contains spoiler information about the solution
Tip: Read the notes in the "Modulo check confirmation example" very carefully. There is a bit of important information there that occurs nowhere else in the description.
Loading more items...