This fork runs about 500ms faster, on average

Rust translation. Please review and approve

Note that by simply using a string to represent the previous character seen and filtering after sorting, we skip having to re-check the entire output slice (or string) repeatedly to determine if we're looking at a duplicate.

I think this is likely to be the fastest possible solution, since it runs in constant time.

I was inspired by another solution to refactor mine for readability

check that the output is made of the expected type of data

For some reason all fixed inputs are tested using the reference solution despite clearly having only 1 possible result each :\

Added sample tests to fixed tests, and rewrote the "out of bounds" assertion.

as cocky as usual! x)

You don't get the point. Look at the way doc's doing this kind of tests in his hard katas: the first thing he does is to check that the output is made of the expected type of data. This way, the user get a useful assertion if he does something (very) wrong instead of a nasty total crash. So that's actually a valid issue, even if you don't like it. ;) (see this as something that can improve the experience of the user ;p )

What are you even talking about (both of you)? There's an example in the description telling that the output should be formatted as ["down", "down", "right", "right", "up", "up"].

it should be simple enough to explicitly cast the number to a string

Except I can't read your mind, and I can't tell how you managed to express cardinal directions through integers.

Anyway, not an issue.

na, what I mean is that your solution should return something like ["down", "down", "right", "right", "up", "up"] but it seems that your code puts numbers in there. So there shouldn't be anything to cast to string, actually. But effectively, the test function should warn the user about that, rather than just fail when a wrong data is found in the returned list. ;)

EDIT: well, a forced cast to string would be a soltuion too, yes... x) Tho, the other way would be better.

Oh, I agree that my answer is wrong (though I've yet to track down why), but it should be simple enough to explicitly cast the number to a string.

seems you're returning a list with numbers instead of strings, so that comes from your side. But the tests should effectively be made bulletproof, about that.

I'm working on the Python version of this Kata and there seems to be an error the way the tests are printing errors (?)
Here's what I keep getting:

  File "main.py", line 62, in <module>
    do_it()
  File "main.py", line 61, in do_it
    perform_testing([[random.randint(1, 100) for x in range(size[1])] for y in range(size[0])], (random.randint(0, size[0]-1), random.randint(0, size[1]-1)), (random.randint(0, size[0]-1), random.randint(0, size[1]-1)))
  File "main.py", line 48, in perform_testing
    Test.assert_equals(assert_path(t, start, finish, user), assert_path(t, start, finish, correct), "Your path is more expensive than it should be")
  File "main.py", line 19, in assert_path
    else:                 Test.expect(False, "Invalid direction: " + move)
TypeError: must be str, not int```

By parallelizing the calculations into chunks of 50 numbers, we get massive speedups for longer ranges. Every run of this is under 200ms for all tests, even in bad random test scenarios, despite the String operations including regex and the Arrays.sort call required to get the output properly formatted.

Recursive algorithm running ansynchronously. Finished all tests in ~540 ms.