"Turn it into a string" seems like the wrong thing to do if you're trying to make code run faster. I assume it gives you a faster equality check via a nice hashcode but it still seems dumb.

Puzzle description: Note that ... some elements may be repeated.

Actual tests: no repeated elements
Model solution: wouldn't work with repeated elements

ಠ_ಠ

It is for C#, at least. The C# translation of this kata should be on that 2kyu kata, not this 3kyu one.

Obviously you have to escape the ' or " in your list of possible characters, but don't do what I did and forget to escape the \ too. (facepalm)

My JS solution is a bit of a cheat.

It finds a non-optimal route on e.g. [95,51,56,93] or [75,71,63,92] or [34,17,24,18] but there is apparently no such situation in the fixed tests, only sometimes in the random tests.

It fails to find a route at all on e.g. [94,90,75,92] but again this only sometimes comes up in random tests.

Maybe these should be added to the fixed tests.

Pretty sure this doesn't work in the general case :(

In my case, saying which of the two ways of differentiating tan was expected would have helped.

TBH I'm surprised I didn't run into issues with the ordering of chain/product/quotient rules... or maybe it just didn't come up.

Love it. Made me find ~3 things to incrementally speed up my 6x6 solution, although I presume there are ways of solving this that are much faster and thus wouldn't have needed any extra work. 8x8 will be the end of me.

Yup, this is all on me.

In C#, the sample tests are broken.

Also, Attempt times out for me, and I can't think how performance might be an actual issue here.