Something like random tests should be added to prevent hardcoding. But that doesn't really matter because there's a lot of katas about primes and about palindromes now, combining the two ideas doesn't really add anything new.

Code golf might be fun, but questions like these are the best proof of why to avoid doing it in a real codebase.

Same issue here, worked on my machine and failed for 450010, and thanks to you I changed :math.pow(n,3) |> round to nnn
I guess this is part of the difficulty : you have to know every nook and cranny of the language you use :)

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 is - I think - test 109:

Test 109
  1) test sum_fracts (SumfractsTest)
     fixture:10
     Assertion with == failed
     code: Sumfracts.sum_fracts(u) == ans
     lhs:  {239033687673439875, 44847850151521494}
     rhs:  {79677895891146625, 14949283383840498}

You can see that lhs and rhs are different. Can't you print the input and your ouput?

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.

Isn'it test 109 instead of 111 where you are stuck?

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

missing elixir example within description

You can prefix content with a _ to get it to ignore it, like _content

As you could have seen I slightly modified the description and give a hint in each language where it is helpful. It was one of my first kata, now I'm using some kind of "fuzzy assert" where I test if abs(actual - expected) is less than a given tolerance.
Thanks for your post.

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!

When rounding doesn't fit try truncating since it seems that your value is a bit too high.
I added something about that in "Your solution" for Elixir and you could have a look at it.
Thanks for your post.
I answer late but I have just been notified, CW has problems!

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 :)