Fun problem. Taught me the value of the pop() method which is way more efficient than reassigning lst=lst[:-1]

In C, the Big_Tests and Random_Tests print simply "Test failed" or similar instead of anything like inputs / actual / expected. I understand the input arrays will be quite large, which is also why printing them to stderr is impossible-- the buffer will fill up with passing cases and you fail with Code 137 long before you see the thing you needed. I was able to guess my mistake, which was that my arbitrary upper limit for the values in x[] or y[] was too small. I suppose I also could have printed only the largest one after sorting them each time, but I didn't think of it until now. It worked when I used HUGE_VAL, but in the end, I stopped relying on that comparison.

One way to check if it's reasonable is to evaluate your version of the expresion and check for floating-point errors with errno or the floating point state

See https://en.cppreference.com/w/cpp/numeric/math/math_errhandling.html

Also, you can estimate the error caused by a small deviation using the derivative, which you should already have

This was quite a challenge to pass all tests with distorted inputs. Took more time than expected. Really nice kata!

Thanks! I was interpreting it that way, but I needed confirmation and your formulation is much clearer.

stop advertising.

uff, that´s brilliant, thanks for taking the time to answer the comments.

Very funny kata.

For Java I'm pretty sure JUnit 5 allows to put assertion messages into assert methods. With that, you can properly output the assert notes without workarounds or so (consult with
JUnit 5 example on docs.

About C++, Snowhouse actually allows to implement assertions as well, although in a more tricky way.

Finally, these messages are crucial for true/false checking, because otherwise you can get obscure output about expected true and actual false without any sign on where was that message invoked or smth :/

no answer from OP and no evidence given

Ignoring the $z$ coordinate can give that impression, yeah. You're wrong, author's right. Closing.

Approved

Friendship is commutative. (The description doesn't explicitly say this, but I think it's clear from the example given, which has Harry/Ron but not Ron/Harry.)

Can you post the test case (the first few lines of it, at least) that produced the strange behaviour?

I can't pass the first test case. I had a solution that did return a clique (allowing for if X knows Y, then also Y knows X). The test said there shouldn't be any cliques. So then I coded up a non-commutative alogrithm, and then for the same problem the test harness says there should be at least one (!).