Oh, of course, thanks :)

Elixir translation

Elixir translation added

Answer to myself and maybe others:

The tests do not want to compare the instances, as they (hopefully) are always different.
Take care of this early and all will be fine :)

Maybe this was the same error I'm running into:

Test.assert_equals(Vector.new(1,2,3), Vector.new([1,2,3]))

yields

#<Vector:0x0000559eb6bc3b08 @x=1, @y=2, @z=3>, instead got: #<Vector:0x0000559eb6bc3f68 @x=1, @y=2, @z=3>

in my implementation, although the initialization itselfs seems to do, what it is supposed to.

Maybe a bit too picky :), but the description for Elixir states an array as result when expecting a tuple: {area, volume}

I solved this with Elixir, but experienced, that it depends on a random test, if you pass or not.
I tried several times now and the test case passes. when I do an attempt, a test with randomized data may or may not pass.

It all seems to boil down to accuracy (round nearly always fails for my solution, as floor passes most of the time, but not always)
My first solution never worked with any method and was always one second off with random values.

Thank you for your input.

You are completely right with the specs, though we maybe should handle k=0 in some way, as it yields an unwanted result in the implementation.

I corrected the specs along with the random range for n:

:math.pow(2, 31) |> round |> :rand.uniform |> Kernel.-(1)

I had some issues at first, when setting up the pipeline for the erlang calls.
This still feels a bit clunky to me, but seems to be the way to go here.

Thanks for your feedback, I myself am still not overly happy with this construct.
Normally, I got used to defining small "speaking" functions with guards and pattern matching in function heads :)

As I gave up on PHP in favor of Elixir for some years now, but was "raised" by my former co-workers for like 10 years with a "don't ever use ternaries (for they can make code even more obscure)" policy, I think, the best way (regarding readability) would be, to use a small additional function for this, if one wants to avoid ternary operators.

Elixir translation added.

Please review and accept/comment :D

Elixir translation added.

Please review an approve/comment :)

Elixir translation added.

Please review and approve/comment :)

Elixir translation added.

Please review and comment :)

Just added an Elixir Translation

Please, review and comment :)

For Elixir, that's the same test I also fail at the moment. I tried Streams instead of Enums to gain some performance, but it seems to boil down to the point, that the naive prime check relies on counting the divisor up to 100000001 and 10000000055 by one, which breaks the timeout limits.

I wonder, if we could speed this up or do some other kind of prefiltering magic, like implementing a "Sieve of Erasthosthenes" somehow, but that also sounds quite "expensive" towards execution times.

As I am far from being a "maths guy", I am maybe just missing the obvious here :)

Edit: Just after I wrote this, I came up with a working solution. This does not make the algorithm faster, but spares a lot of unnecessary turns with minimal effort, especially when testing big primes.