Approved.

Approved

Approved some time ago

I might have to take a look at that.

Duplicate issue below

Thank you

@S_OK. Can you please paste and example so I know what you are seeing?

The error output makes debugging extremely difficult. Below the tree I just see my result not what expected. I don't see everything that is after the index of first difference value. This is unfavorable for random tests. If the number of nuts is greater than 9, strange characters are output.

umm yeah, I thought the sharks would just have to wait for the man to approach the pontoon. Maybe in that case the person will still go to the pontoon even though the sharks are already near the pontoon. Swim for nothing

Looks ok, I'll approve the fork. And I'll wait for someone else to confirm the issues are resolved to close them.

@Chrono79 I have forked this and fixed the random tests, not sure if it can be integrated or if that's of any use.

https://www.codewars.com/kumite/5da194ad8fd3c9002af1d7d1?sel=5e7148d4251098002809afd6

Please, check the issues raised about random tests in C# translation and fix them.

the description allowes it, but it's not tested in the fixed tests. => Donald?

Judging by the comments above the C# version should be working correctly. Closing.

I note that the current c# large unit tests do not push beyond the bounds of long integers, and I believe that they should. (I had a good time implementing this in c# regardless.)

// I ran this in LINQPad
var a = CountOnes(0, long.MaxValue).Dump();
var b = CountOnes(0, 910000000L).Dump();
long.MaxValue.Dump();
(b < long.MaxValue).Dump();
(a < long.MaxValue).Dump();

output

290536219160925437952
13397931473
9223372036854775807
True
False

I noticed the range issue after reading a solution that does its logic entirely in longs and only converts to BigInteger in the return. It also returned 0 for inputs larger than half of long.MaxValue (probably because its logic breaks down in that case.)
Thus, it seems flawed that we don't have at least one random test that pushes beyond what fits in a long. I note that the count for the range [0, long.MaxValue] is almost 32 * long.MaxValue.