I lost some good 20 minutes here, maybe more.
This kata is annoying for the right reason.
If you want a tip, get to know your programming language of choice.
Rounding, truncating and floats are common source of problems in computer science.

If you want a further tip: build your own tools, define your own functions, when needed.
If a built-in function accepts an Integer and returns a Float (considering you need an Integer result), you're in trouble, guarantee that you can have your desired result without relying in rounding or truncating.

I really liked this kata, I don't really know why the low satisfaction rating, but I can guess[1].

Issue:

Expected #f, but instead got #f
This was posted as an issue last year but still an issue today.

Suggestions:

[1] I think the description overcomplicates the kata and that's why it is marked as a low satisfaction rate.
You can use longer names as variables/parameters, which is, as far as I know, a good practice in Lisp, instead of using "v_r", "v_s", etc.
They're not even in the most accepted style used in Lisp which is to use hyphen conventional symbol names instead of underscore.
I don't think the extra-work and confusion about the symbol names worth and it doesn't add any value to the kata description or to the practice or learning, specially considering a 8 Kyu kata.
But hey, that's only my opinion.

[2](check-= (swim-distance 10 5 5) 11.1803 0.001))
This is also a question. I don't know the implementation of check-=, Why do the 0.001 as a parameter?
For a good moment I was totally confused about what I should return, as the description said to return the distance but there was more parameters in the test case.
Although as they're not as a list I should have just guessed the 0.001 was not relevant to test my solution, but still, since looking at the test and writing your own tests is part of how codewars is used, I think the test function should be improved to be easier understood and read.

[3]In case of invalid input values (e.g. negative river width) the function should return 0.
A negative river width is conceptually an invalid input value, but not practically, the tests will always pass and this is everything I can say without spoiling the solution.
Also, in my humble opinion, the cases where the swimmer velocity is zero and the river width is zero should be stated in the description instead of the wrongly stated (and irrelevant) negative river width case.
It's lame to have to fail just to see that you need to implement those two easy test cases...
This is again a problem of lacking of description.

In general I liked this kata a lot. As simple as it is, I liked it more than the majority of katas I've done in codewars so far.
But I think the lack of clarity in the description doesn't add value to the kata. You can just make a clear description and if you think people will solve the problem too easily, think that it is a 8 Kyu kata, it should be easy anyways.

@hobovsky thanks for pointing it out!
I confess I've only noticed the tag in this one after reading your comment and checking it again.

Thanks for replying @jessedo. Can you tell me what kind of assertions did you do to solve this kata, so maybe I can learn something?

The rest of this reply is a rant, read only if you don't mind to interact further. :)

I agree that programming isn't only about coding skills, still I can't see how this kata can be useful.
I've read a good bit of the discussion thread, and there is a lot of interesting replies both from people complaining about the kata and from people defending it.

A lot of people are talking about this kata "teaching" TDD and making assertions regarding the result and testing, but you should not write code to pass tests, and as someone have said, TDD isn't a basic concept so it would not be 8, 7 and maybe not even 6 Kyu anyway if it was really focusing on practicing TDD.
Even if it was the case, there is no teaching since the description is very bad and focused on tricking and joking, and it would not be teaching something exactly correct if it was the case to exploit the tests to make assertions.
(Although, if you or someone is writing code to pass tests, that's good for you that it's working in your job, I would be fired, and I'm not familiar with this passing-tests programming paradigm.)

Another thing that this kata have is a poorly written description.
Not only it's bad to be poorly written per se, but it also difficult a lot for people that aren't native and/or don't speak English fluently.

This is an interesting math trick, but I can't blame people that didn't learned about it or that couldn't spot it.

This kata should, at least, have a clearly description if it's really trying to teach something and to offer any kind of practice even if it's not about code, and forgetting about jokes, although a "jokewars" would be cool, considering the fact that you would be entering knowing that it's about code goofs, oneliners, "troll code", etc.
I know this is a long rant already, but this makes me realize that since the katas are not "professionaly created" (I mean, by teachers, really focusing on teaching something when it's not the case of "useful" practices), codewars should implement a "tag" system, so people can tag it as a joke, goof, annoying or whatever, and people that aren't here for this can just filter and avoid it completely.

In Racket my testcase for epsilon 0.1 finishes in 3 iterations instead of 10.
Also my testcase for epsilon 0.01 finishes in 25 iterations instead of 100.
Etc.

I don't know what kind of implementation are you waiting for, should I write my algorithm less eficient just to pass the test cases?
I don't get it, I'm recursively creating Libniz formula 1 - 1/3 + 1/5 - 1/7 ..., exactly what the kata is asking for, still the way the test cases are written I just can't pass, although I'm converging correctly to π.

I'm marking this as an issue, although I don't know if it is an issue.
Did I understood the Kata description poorly? Let me know.

Log epsilon = 1 actual = (1 4.0) expect = (1 4.0) epsilon = 0.1 actual = (3 3.4666666667) expect = (10 3.0418396189)

Log 0.00014 epsilon = 0.00014 actual = (1786 3.1410327432) expect = (7143 3.1417326508)

This might be something related to how different languages deal with float, big numbers, etc, and maybe the result can vary from lang version to lang version. I'm just guessing.
Only 6 of 3893 completions was in Racket, did those 6 completions used the current Racket 7.2 or another version?
Did the test cases where the same when they completed it?

I'm honestly not sure if the problem is in my algorithm or in the test cases written for this language/version.

This is the best kata I've found so far in codewars.
The majority of kata is either math focused or not about code practice at all.
This kata however, focus on practicing concepts about the language the kata was designed for.

I like math, and I understand the importance of a good math background to be a flexible and creative software engineer, but some kata are either out of place or make you lose time with tricky descriptions or loose test cases.

I have the same problem in Racket.
I can't even see in what test it is failing, it only returns "timedout" without further explanation.

What problem are you facing?
What language are you using?

I understood the joke but it's honestly the worse kata I could find on codewars.
If "This kata can be more difficult than regular 8-kyu katas (lets say 7 or 6 kyu)", then it should be 7 kyu or 6 kyu instead.
If "This is not about coding skills", it should not be in "codewars".

At this point I might be visiting codewars for some math fun, because there is a huge amount of problems that's not really "code" related.

It is fun and not that hard.
But I think, as a couple of others, that it's more of a mathwars than codewars.
Although the math is not really advanced, is not very basic as well, I would rate it as a 6 Kyu instead because of the slightly elabored math involved for the optimal solution.
The real "code challenge" for this kind of problems is when you don't know the "math solution" or couldn't remeber/figure it out.

It is not a hard kata, but depending of the language you're using you can be lacking some Array/List facilities and will demand some thinking.
I agree it's more of a mathwars kind of problem.
I suggest you to write it down step by step with pen and paper if you want to spot some error on your reasoning.

I forgot to remove "nth(N, L) -> lists:nth(N, L).", it was for another solution I was trying.