When you have only 1 function, the use of the pipe macro is not recommended.

Already did that and I still mantain my opinon over the kata.
The point of an exrecise is not to force your students into using the same methods you use, but to encourage them to find their own solutions.
Unfortunatly, this specific kata, with all the rounding issues and inconsistent tests doesn't accomplish that.

Your other katas are really good though. Don't feel discouraged!

Already completed the exercise, though I am not realy happy because it randomly passed the random tests...

Worst kata ever. Seriously.
It finaly worked and passed the random tests, but I didn't change the code.
I get I got lucky since the same code failed several times before.

You are correct. The number of seconds is 7920.

However calculate that value, the imprecision in your solution adds up and thus even though I produce a valid result it fails all the other tests.

For this reason, I have to subtract one to the total number of seconds:

defp seconds_to_catchup( slow_distance, fast_distance, _, _, secs ) when fast_distance >= slow_distance, do: secs-1

This way, it will pass all tests, except the corner case I mentioned. It still isn't a satisfatory solution because I am still fighting against the accumulated loss of precision your solution generates.

I am sorry but I strongly doubt of that.

Since my solution's caclulations don't round numbers, this is not a matter of opinion. It is a matter of mathematics.
If your solution does, it will be inherently less precise, which is the problem most users of the kata complain about.

Maybe you should reconsider the way you made the calculations (in particular don't divide by 3600 too soon).

Fair enough. Let's take a step back and analyse my decision making:

def race(v1, v2, lead) do
    slow_speed = v1 / 3600  #v1 feets per second
    fast_speed = v2 / 3600  #v2 feets per second

    seconds_to_catchup(lead, 0, slow_speed, fast_speed, 0)
    |> to_compound_date()
end

Why do I divde by 3600? Becasue I want to convert from feets/hour to feets/second.
Now once I have this calculation, I can simply iterate each second and add the distance travelled within that second, which is what seconds_to_catchup does.

I believe you have picked another avenue to solve this problem, likely just as valid. However a good exercise should not force a path upon the user. I don't know how you think, I can't know your algorithm.

But my algorithm, converting from feets/hour to feets/second, and working that way is mathematically as sound as any other.

I understand my answers may be harsh. I don't mean to attack you nor your skill, I am this way because I care.
I also understand you are trying to help out, but truth is I feel quite frustrated when a mathematically proven solution isn't good enough to pass a simple exercise.

I mean, I wold totally understand if you were to tell me something like "Your conversion from feets/hour to feets/second is totally wrong.", as that would no doubt have a great impact in my algorithm and make me look like a complete idiot.

However, when the maths in my solution are sound and it still fails, it just frustrates me that I have to find another solution, more simillar to the one you considered.

Maybe it is my personal belief in action, but this is not the way Codewars exercises should be.

Kernel functions don't need the Kernel prefix on them. You can use them directly :D

Using Streams to make a lazy evaluation of the operations.
Another alternative would be to compose multiple maps into one function and thus iterate only once, but I think this solution is now good enough.

In order to reduce the amount of magic numbers in this solution, you could have used a module attribute to save the base value of 40:
https://elixir-lang.org/getting-started/module-attributes.html#as-constants

This is quite literally how you shoud not do an exercise.
You simply checked for all the test cases and hardcoded them all.

What if tomorrow the zoo gets another anmial? Will this function have a case for all of them?
This will be impossible to maintain.

Check the other solutions and remember: pattern matching is your friend :D

When you only have 1 function in your pipe, community rules suggest you avoid using it. I.E.:
splittedStr = str |> String.split(["_", "-"]) should be: splittedStr = String.split(str, ["_", "-"])

Good solution, you can improve readability by replacing &( String.length(&1) ) with &String.length/1 though.

Kudos++ for the documentation that we always forget :p

Completely agree with this comment. This solution is not even Tail Call Optimized.