From the description:

The numbers will also all be unique and in ascending order.

From the description:

The numbers will also all be unique and in ascending order.

xrange is python 2 and has the same behaviour as range in python 3 does. In python 2 range(*args) did what list(range(*args)) does in python 3 so for iteration (like the for loop), xrange was the better choice.

Unless performance is an issue, this code is much more readable. Any programmer can look at it and instantly tell you exactly what's going on.

In the details you have

Considering that the tangents lines have the equations of the form:

(tangent1) y = m1x + n1x

(tangent2) y = m2x + n2x

but considering the "Let's see some cases" code block, you probably meant

(tangent1) y = m1x + n1

(tangent2) y = m2x + n2

My issue was simply due to speed. The test mazes have size 1, 2, 3, ..., 99, 100, but this is reapeated 6 times, so you need to be able to complete the first 100 random tests in less than 2s to pass.

Instead of using .Where(predicate).Count() you can also just use .Count(predicate), though the first one might be a tiny bit more readable for anyone.

Not quite. The eratosthenes sieve, doesn't remove every k-th entry, it just markes it as not-prime. Here, we actually remove the entries from the list, which will change the indexing.

Unless the sequel concerns recognising this situation in a program and having the compiler optimise for it, of course.

I don't, it just always irked me that doing Enumerable.Min and Enumerable.Max is potentially up to twice as slow, even though this won't really matter for small collections and simple selectors.

Alright, it turns out my implementation was just simply not quite fast enough. I managed to pass now.

Oh, I'll play around with that. Thanks for your time.

This doesn't really help in my case, as I don't get to see the console output if the execution times out.

I even added more tests with some of the 100x100 mazes from the randomized tests, which made it even more evident that my code probably should be performant enough, as each additional large example only added about 40ms.

I'll add my code in a separate, spoiler-marked comment.

For the C# version, something seems broken for larger mazes. I can pass all the tests up to a 99x99 grid in about 2.2s, but I time out if I had not hardcoded an (obviously wrong) answer for larger mazes. My solution does work fine for a 100x100 maze I put in the sample tests manually (and completes that test in less than 100ms). I'm not sure where the issue lies.