The ordering is, in fact, lexicographic. In this case the "alphabet" is the set of numbers that make up the sequence. I don't think that saying they're sorted "numerically" has a very precise meaning.

The second solution on the solutions page takes the naive approach, which is pretty slow for n = 10, but still doable (there are about 3M permutations for n = 10). There are also a number of well optimized solutions to that one, but it's not a requirement to get the job done.

Note also that a straight adaptation of that kata would be totally trivial in ruby, because of the permutation method on arrays.

I've renamed to "Find permutation at index for large N". I don't super love this title because the "large N" bar is only 100 – enough to ensure that you aren't using a factorial time solution. Open to other suggestions though.

It's actually not an exact duplicate. Per that kata's description:

The function should work for any d between 1 and 10

Per mine:

Your solution will be tested with n as great as 100, and should not time out.

This detail is key, because the naive, slow solution of iterating through every permutation will work on the kata you linked, and will not work on this kata.

But I'll rename this one to make the differentiation clear.

Great, marking this as resolved then.

What browser are you using? These are rendered with SVG, and it's possible that your browser is drawing them incorrectly. In the second test case, the point is well inside the square, and in the fourt test case, it is well outside the square. In the sixth test case, the point is very much inside the triangle.

I've checked this in Chrome, Firefox, and Safari, and in all three browsers, it renders correctly.

It's defined in the "preloaded" part. I don't think you can see that when training on a kata.

Feel free to add it yourself - it's open for contributors. It shouldn't be too hard to port the poly drawing part too - it just spits out some pretty basic svg.

The real test cases are very carefully written so that the point will never lie on the exact edge. It is possible that your browser is displaying it incorrectly if that's what you're seeing.a

with input "[ [ -1, -1 ], [ 9, -1 ], [ 4, 9 ] ], [ 1, -3 ]", The point is obvious outside the polygon, But it said it should be inside?

What test is that? There's only one quadrilateral test, and it's a square from [-5, -5] to [5, 5].

Which language? I checked JS, CoffeeScript, and Haskell. In each, the third test expects the point to be outside.

What is there to explain? Arrays have a length property. It's just a normal path.

The test that includes "yadf" also passes a comparison function.

You have to count the number of arguments specified in the path to figure out how many arguments you need to accept. So for example, if the path was "foo(2).bar(1)", you count up the total arguments, and find that the next 3 arguments will get passed. If there is another argument left over after that, you use it as the optional function.

As kirilloid said, it sounds like you aren't handling the path.

It seems like the C# version has a lot of problems. Someone else contributed that, and I don't know C# myself. Not sure what I can do about it.