It looked like the version for codewars is 2.6 (https://github.com/Codewars/NUnit-codewars) and the docs I was looking at were http://www.nunit.org/index.php?p=equalityAsserts&r=2.6

I'm not an expert in it though I've just been using a few assert functions like AreEqual

That should work! I just tested it, it looks like if you put a constructor in your test class
public SuiteTests() {
GlobalSettings.DefaultFloatingPointTolerance = .000002;
}
it will use it everywhere, that way you don't have to change any tests.

BTW the reason why I grouped rounding / truncating is they are pretty similar in how they work, it's easy if you look at it on a graph! (hopefully the link goes through)

http://www.meta-calculator.com/online/xg82tkvrqybi

I used the floor() function like you use in your solution, the other line one is round().

Yes, for C#, I noticed that that the test case used an open source framework called NUnit. I tested it just now with the example test case, and if you change the first one to Assert.AreEqual(1.275, Suite.going(5), .01), it sets the tolerance to .01. It's a common task so I'd hope other frameworks build it in but I don't know if you can just add another parameter in Haskell :)

For the example say for test case 1 the expected math result is .9999999999. And the truncation rule is 0 decimal places, so .9999999999 will get truncated to 0. Then a user solution is .0000000001 too high because of floating point precision, and it comes out .9999999999 + .0000000001 (due to floating point error) == 1.0000000000 Now when the 1.0000000000 gets truncated it will be 1, which does not match the expected result of 0. So even though the solution was only .0000000001 too high, it fails the test case.

Using the same rounding, say for test case 2 the expected math result is .5000000000, truncated to 0 places that would be 0. Say the user does the math wrong and they get 0.0000000000. Truncated that is also 0. So that test case passes. Using the same rules, for this test case a solution .5 off can pass, while for test case 1 a solution .0000000001 off will fail.

It works the same whether the numbers are .000999999 with a .000000001 positive error making it go up to .001000000, then being truncated to 3 decimal places to .001 or .000, everything is just moved over a few decimal points. Something similar is happening in one of the test cases for this problem.

So rounding or truncating seems like a good idea at first and the obvious way to do things, but the problem is for numbers close to the rounding / truncating point even a small precision error will change the result (and numbers far away from the rounding point will have 100x more leeway). It's just super unlucky that one of the test cases in this problem has a number that ends in 9999999999 (when stored in a double).

That make sense! Also with so many languages for this kata it might be confusing if they were too different.

Hi! I also noticed the rounding issue.

The task asks for 1.2125, but that is a repeating fraction that can't be represented exactly in binary (like 1/3 is .333 etc in decimal), so once put in a double it is around 1.2124999999999999. When the program correctly truncates that to 1.212499 it fails the test case.

In general rounding won't work math wise for comparing floats, because it will tolerate a varying amount of error that might be infinitely small. For example if you are truncating .9999999999 to 0, with only .0000000001 error it will truncate differently to 1. But for .5 you can have a whole .5 of error before it will change the truncation.

Luckily this is really easy to fix, the testing framework already accounts for this and you can just add a third parameter to Assert.AreEqual(expected, actual, tolerance) which is the tolerance amount. If you make this value large enough, say .0000015, it should work with all the existing solutions too.

Thanks!

C# should probably also be changed to match convention... unlike Java GetX() methods aren't the way accessors are written in C#, so practicing this in C# should probably use properties instead.

Some of the submitted results only check the first two operands, test cases should catch that (I don't know if this was fixed already).