Ad
  • Default User Avatar

    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.

  • Default User Avatar

    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.

  • Default User Avatar

    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.

  • Default User Avatar

    Then it will return mocha_missing, as per the specification.

  • Default User Avatar

    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.

  • Default User Avatar
  • Default User Avatar

    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 my decode won't).

  • Default User Avatar

    "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 :-).

  • Default User Avatar

    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 empty swaps 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.

  • Default User Avatar

    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?

  • Default User Avatar

    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:

    swaps = [[0, 9], [9, 3], [3, 7], [7, 8], [8, 2], [4, 5]]
    Test.expect(find_the_ball(4, swaps) == 5, "Nope! Expected 5.")
    
  • Default User Avatar

    OK, I've done that. I think it was only the Ruby version that's affected - I didn't write that one :-).

  • Default User Avatar

    The word "swap" implies bi-directional. I'd have written "move" if they weren't.

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    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...