We can't raise it. It's approved at 4 kyu, the average vote.

Do you think I should raise it to 3kyu?

I do think we underestimated the difficulty level of this kata. I don't think anyone has solved this kata yet after approval.

Yeah, that's really weird. I tried running your solution and I couldn't get the print statements to work (except for the first one, for some reason. If I remove it, nothing is printed at all). I read the test cases and found nothing that may prevent a print statement from executing... not sure what's up.

True, it's quite strange... if I were to take a guess, I would assume this is a symptome of trying to print a dict of this size: while it's useful to see the example tests' ingredients to find the cause of any bugs, it's pretty much pointless on the performance tests, because there's too many ingredients to check.

Actually, it's straight up counterproductive because print statements impact your performance: if I were you, I would remove print statements when I'm going for the submission rather than the example test cases. As stipulated in the kata description, example test cases should be enough to confirm your algorithm is correct, so you shouldn't need to "debug" performance tests.

Oh, you meant the print("goal flavour: ", flav). I thought you are talking about print(results_list).

You're right, that's pretty weird.

The second print there doesn't execute because there are 26^2 ingredients.

With that amount of ingredients, currently your code is checking this many possibilities:

\frac {(26^2 + 5 - 1)!} {(26^2 - 1)! . 5!} = \frac {680!} {675! . 5!} = \frac {676 . 677 . 678 . 679 . 680} {120} = \frac {143266201216320} {120} = 1193885010136

Of course, checking all 1 trillion possibilities would be very slow.

tropical paradise, performance hell

Then I guess the people who already solved it must have prayed very hard :-)

More seriously, if you can articulate why you think the knight can always check the king, maybe I can give a hint where you might be making a unwarranted assumption.

Are you saying the problem can't be solved?

No - the knight can see where the king is, but the king cannot see where the knight is. The challenge is to avoid being checked, no matter how the knight moves.

it does have to change direction: first going up from -5 to -4 to pick up the first call, then going down from -4 to -7 to pick up the second call

maybe you rely on undefined behaviour or a feature that doesn't exist in this nodejs version.

if you put

  console.log("oops, reached end of function")
}

at the very end of your function you can see that you don't always execute a return statement

so something is definitely funky with your code (it's not caused by version difference though, just a number of bugs, so when you say it works locally with the same string then you are probably using a different string because no it doesn't work there either)