nope, not anymore x) (the first comment of a thread is the only removable one, but only as long as there is no answer. So.... too late x) )

Ooops, sorry, this comment applied to Pathfinder #1, not #4 - I'm not sure how I manged to post it here!
Can you delete it?

You do need to be fast. In the C# version there are almost 2000 tests and you only have 12000ms, so that's only 6ms per test! The largest mazes I've seen were 100x100. For me, the difference between failure and success was converting a LINQ 'contains' function to checking an array of booleans.

I feel that performance constaints like that should be clearly stated in the instructions, not left as a nasty surprise that we only discover after passing all the sample tests.

my evil twin enjoys the thought of people bashing their head on the keyboard when they find they jumped to some wrong conclusion by not reading the spec

He'll be happy to hear that I completely missed the rule about trains that start at a station...

(me puts down his tin-foil hat...) oh now you're just being paranoid! :)

Hey, thanks for feedback.

In general

• Yes, I keep my example tests short and treat them pretty much as "sanity" tests.
• Yes, I do often put tricky stuff only in the "hidden" tests. It's deliberate:
  • Main reason is to train the habit to read instructions carefully.
  • Second main reason is my evil twin enjoys the thought of people bashing their head on the keyboard when they find they jumped to some wrong conclusion by not reading the spec
  • Also the CW "Validate" button makes it easy to author things that way...

FYI - I do all my coding only in CW editor - maybe I am old-school, but I don't want some machine to think for me. That sounds too much like skynet. Code auto-completion is probably step 1 of their master plan.

And those working straight from the CW editors are just bad-ass. I can't live without intellisense right now ... :D

I just printed the track layout at the start of every run and copy pasted that in text files... :-)

Another great one, thank you!

I really like how your descriptions are intuitive and make the problem sound simple, but the actual implementation is quite tricky. Problems are always bugs in my code rather than unclear requirements - if only they were all like that!

Personally, I'd have prefered most of the tests to be available in the example box so that I could paste them into VisualStudio and use its debugger. Here I had to recreate lots of the 'hidden' tests, which isn't a big problem, but it's nice when I can just copy them and gradually improve my code to address them one at a time. Maybe that's supposed to be part of the challenge? Or maybe people who use other languages do all their work in the CodeWars editor?

OK. I changed the description. Thanks for the feedback.

BEFORE

It must be possible to follow the line with no ambiguity (lookahead of just one step).

AFTER

It must be possible to follow the line with no ambiguity (lookahead of just one step, and never treading on the same spot twice).

Another great kata, thank you!

One suggestion though: the 'breadcrumb' tests require a rule that I don't think is adequately covered by the description. "If you come to an ambiguous corner but you've already visited one of the options, then it doesn't count as ambiguous."

People who don't recognise the cultural significance of Hansel and Gretal leaving a trail of breadcrumbs might not realise why those tests count as valid lines, and not ambiguous loops. Is the story widely known in (for example) East Asia?

Fixed. Thank you for raising this issue.

I think there's a mistake in the C# description. The 'progress as we near an "interesting" number' section has zeros for all the expected values.

I agree. I don't know what TestTools is, exactly. In order to work on this offline, I had to rewrite the tests to use CollectionAssert instead. Katas should not have external dependencies that aren't provided. Maybe TestTools is something that Codewars offers, but I just can't locate.

I really liked this Kata because it's about OO programming rather than maths, but I found it frustrating that many of the tests check behaviour that is not specified in the description. A well written programme would probably throw a ArgumentOutOfRangeException if you try to create a car with a negative amount of fuel, or refuel by a negative amount - here we have to work out the required behaviour by reverse engineering the test.