Someone even checks if they are equal, causing [false, false] to return true.

Test cases are sadly lacking ..

Thanks for the link!

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

I made the change, thanks for the tip! Could you give me a good link to the NUnit Framework?

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.

It seems that the problem is only with C#. ASAP I will try with a tolerance of 0.000002 in C#. What do you think of that?

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

Are you talking about C#? I don't see from MSDN that Assert.AreEqual accepts tolerance as a parameter but I could be wrong... Unfortunately there was no guide for that at CW and there is not one, even now.
I wrote this kata rather long time ago. I used the DELTA parameter in Java for this kata and now for this kind of kata I'm using a kind of assertFuzzyEqual in all languages. Nevertheless lots of guys passed the kata (373) which proves that it is doable:-)
BTW I don't see very well how you truncate ".9999999999 to 0, with only .0000000001 error". Furthermore I didn't ask for rounding but for truncating. The problem doesn't come from truncating it comes from the way languages work with floating numbers and from the order in wich operations are done.
Give me some reference for Assert.AreEqual with a tolerance parameter and I will try to modify it when I have time but I am afraid that tolerance doesn't exist in the other languages.
Thanks for your feedback.

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

You're right,

however the point of this kata is to create a simple class with some methods not a best practice class.

Aside from that, considering how many people have done this kata it's a bit to late to change : )

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