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.
Rust translation, please approve
approved.
Ok.
Now, on full tests, if there is an error and there are more then 20 elements, index, size, and only 5 elements around the problematic one are displayed.
Can you approve it now?
Yes, arrays with >100 elements tend to be useless for visual comparison.
However, it is important that the user be able to actually compare their result to the expected output, even if this means copying them into an IDE and running some manual check.
One could argue that any bugs or logic errors in their solution would have been caught and fixed after completing the smaller tests, making it fairly unlikely to not also pass the larger tests (except due to performance, in which case the actual output isn't relevant). On the other hand, there might be edge-cases only present in very large inputs.
One way to get the best of both worlds is to manually perform an element-wise comparison between the two vectors, and on a mismatch, only present a small slice of the arrays where the error occured, together with an index, as was done here and here. It's more work, but gives the user a more pleasant UX.
It's up to you to decide how best to proceed.
Rust translation. Please approve.
Ok, done everything. Just one question: in big tests, maybe I should provide only the input data? Or no data at all? Like,
A few notes:
Please add proper assertion messages to every test; "proper" meaning useful information clarifying what "left" and "right" are, what the inputs where, etc.
In case performance is a potential hurdle to solving this kata, note that while Rust runs tests in parallel, they are joined in alphabetical order; it's useful to give small tests (that are more likely to succeed even if larger tests time out) a lexicographically smaller name so they appear first.
Please add
todo!()
to the solution setup so that it compiles out of the box.Nitpick: consider running your solution through rustfmt ;)
Very clever! Good catch that you didn't need to translate '456', as their position remains the same.
Rust translation
Please, review and approve
C++
It can't be both together. If the function only checks if the array is wave sorted, it shouldn't check if it stays the same.
It's even worse: i've added
at the beginning of my function, and still it returns "The vector content should stay the same". So, my function only runs if the check function fails - and still the vector should stay the same?
Perfect example to learn "loop for" inside join method
very goood
cool!
It seems to be. Thanks!
Fixed (along with C translation warning) in this fork. Please approve.
Loading more items...