Sorry, I didn't make it clear but the log I pasted in the first post is all that I see. To explain what this is, there is an immediate IO.puts of lst upon entering the function and an IO.puts of the result just before exiting.

However, as we can see in the log, it just prints "Test 109" and then it dies. This why its so confusing for me, and it would make more sense if it is Test 111. Regardless, there is no lst for the failing test.

It could be Test 109 - I am not sure how to interpret the output. It is "Test 111" that is red and outside the expandable "Log" div. But it is "Test 109" that is the last output in the log.

But regardless, if I add those two tests listed in the output above that I have pasted, my local tests still pass. I am not able to inspect whatever test input is causing my code to fail (be it 111 or 109 or something else).

I am not sure if you can help me, it feels the log is printed in the backwards order or some weird stuff like that.

Hello!

I am getting stuck on Test 111 (Elixir), and printing the input doesn't help as it's getting lost in the truncated log that is output:

sum_fracts (13.6ms)
Test 111
 Log
 lst = [{3, 4}, {3, 5}]
result = [{27, 20}]
Test 110
lst = [{39, 40}, {39, 41}]
result = [{3159, 1640}]
Test 109
  1) test sum_fracts (SumfractsTest)
     fixture:10
     Assertion with == failed
     code: Sumfracts.sum_fracts(u) == ans
     lhs:  {239033687673439875, 44847850151521494}
     rhs:  {79677895891146625, 14949283383840498}
     stacktrace:
       fixture:18

Since I do not know how to reproduce this, I am stuck and sad panda.

elixir example added to description

Hi, thanks, that worked. Now my answer was accepted. Still, confusing... I wouldn't have passed without your special hint.

I saw a solution from another person that had the same 'problem' as me; # instructions say round, tests expect floor

I know it is very seldom the case, but.. maybe the correct answer should be revisited? Since more people have problems with round, and also because it is quite disappointing that while there are VERY clear instructions for rounding rules it STILL ends up in having to use floor :-x

PS: I loved this exercise, props for keeping me entertained with math-related programming. Satisfying two interests of mine in one hit!

Hi, itsa me again, Mr Float Issues.

I am getting the number of iterations right, but the rounded value of PI is wrong. Example:

> testPiApprox 5, 6.001e-5, [ 16664, 3.1415326439]
     lhs:  [16664, 3.1415326440]
     rhs:  [16664, 3.1415326439]

(this test case is shamelessly extracted from codewars using the foul play of IO.puts)

When using 15 decimals I see my solution returns 3.141532643988316 so it is rounded -correctly-, ergo the sum must be wrong.

Is it a floating point precision issue again?

Any hints to put me in the correct path? I am really excited about my solution and want to share it, but I need to fix this first :)

Hi, thanks for asking.

Maybe this (equivalent method) here will sort it out with help of parentheses:

(a |> Enum.map(&(&1*&1)) |> Enum.sort) == (b |> Enum.sort)

Neither a nor b is guaranteed to be sorted.

The template has invalid syntax (Elixir)

defmodule Longestconsec do
  
  def longest_consec(strarr, k) 
    # your code
  end  
  
end

It needs to be def longest_consec(strarr, k) do in order to be valid syntax.

With a little help from my local elixir community it was pointed out that floats have poor precision and just like you say if I manage with Integer all the way it worked. I just had to "hack" ceiling operator :)

I have completed this in Ruby now and for the final case 3000/4187 I had to wrap every term and product in BigDecimal or I would get rounding issues.

Now, I have almost completed it in Elixir and have the same issue. It is rewarding to battle with algorithms and good code to cover all test cases, but it is frustrating to combat with floating point precision.

  1) test decompose (EgyptfractTest)
     test/egyptfract_test.exs:9
     Assertion with == failed
     code: Egyptfract.decompose(s) == ans
     lhs:  ["1/2", "1/5", "1/61", "1/9090", "1/105529529", "1/30625323994615532"]
     rhs:  ["1/2", "1/5", "1/61", "1/9090", "1/105529529", "1/30625323994615534", "1/3751641879100695842954773901805090"]
     stacktrace:
       test/egyptfract_test.exs:19: (test)

Any suggestions or helpful comments to help me pass the final step - which is like Mt Everest :)

Locally in Elixir v1.2.5 I get Pilecubes.find_nb(10252519345963644734526) == 450010, but when the code runs on their server (Elixir 1.2.4) it gives -1...

Afaik this seems to be a bug in elixir.

On codewars the volume for n = 262144 becomes 1180600627933845935062, but locally in elixir 1.2.5 this is actually 1180600627933845923710. For values of n < 131072 this math error is not noticable. For even higher values of n this error becomes more noticable of course.

EDIT: Actually, it was a rounding issue. Used math.pow and round instead of n*n*n