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.
The final swap swaps positions 0 and 1. But at this point the ball is under position 2. The shell at position 2 is not involved in the swap, so the ball doss not move.
The tests don't use the order, or the specific value, of thread IDs. They just use thread IDs to identify how many threads were used, and which numbers were grouped together in the same thread. The only thing it relies on is that each thread has a unique ID, which is guaranteed.
Each move is a swap of the two positions, so the order of the tuple doesn't matter. The second move swaps positions 1 and 2. Since the ball is in position 1 at this point (because of the first move), the ball moves to position 2.
Then it will return
mocha_missing
, as per the specification.I think I had to. For a local variable to be captured by an anonymous inner class (and so by extension a lambda expression) it has to be final.
Yes.
I realise this is just suggesting that you break my solution, but, if the encoding and decoding can fail it's probably worth adding test where that will happen. (I think my
encode
will cope, but I know mydecode
won't)."The input will always consist of one word (no spaces)."
But if you still think it's wrong - don't tell me, tell the person who wrote the tests :-).
I'm a little confused as to the error you're reporting, because
find_the_ball(1, [])
is not one of the test cases. There are no test cases for Ruby with an emptyswaps
list (although returning the start position would be the correct solution if there was)....Aha! Got it. Multiple tests used the same
swaps
array. But your solution mutates that array, which means that the second time it's used the test that's being run doesn't match the test it thinks is being run.I've changed the tests so that this should no longer be an issue, but I would point out that it's poor practice to mutate the array passed in like that, for precisely this reason - it can lead to hard-to-find errors.
That's not a solution to the problem. Have a look at mcquackers' earlier comment and see if that helps clarify things.
If you still think there's a problem with a test, can you tell me which one?
I'm looking at the test cases, and I can't see any like that. Can you give any more details? The code for that test (just copied from the editor) is:
OK, I've done that. I think it was only the Ruby version that's affected - I didn't write that one :-).
The word "swap" implies bi-directional. I'd have written "move" if they weren't.
This comment is hidden because it contains spoiler information about the solution
I thought that at first, but then realised that answer is disallowed by the statement "All of the ?s in an expression will represent the same digit (0-9), and it won't be one of the other given digits in the expression".
Loading more items...