I was actually trying to avoid Math.Sqrt. I figured a 2.1 billion iteration loop takes less than 10 seconds locally, so it seemed logical. I didn't realize there were so many extra hidden tests running in the background! When I clicked 'Test', it passed fine, but it timed out when I hit 'Attempt'. Thanks for the heads up, my bad! :D

Your code being too slow is not a kata issue. You need to find a better approach :)

What will your code do for n=3?

Use System.Math, library is unknown.

your code also has Convert

both can be available by having using System; at the start of your code

In C#, fully qualified name of the class is System.Math.

Math does not exist in current context, why?

Same for me.

Being not able to fix the rounding error in a solution is not a kata issue.

Expected: 702912415374435841
But was: 702912415374435840
How am I supposed to fix the rounding error?

Nice excercise

Could you link to an example that is passing despite not being "float proof"? The top C# answer by g964 seems to be float proof. It correctly returns -1 for 4503599627370497 and correctly returns 67108865 for custom test case 4503599761588225 (which is greater than floating point precision 2^52 = 4503599627370496) (I did my math through wolframalpha which is more precise than Google's calculator).

C# does not lack precision to solve this test, and any problems with precision are introduced by a buggy solution, not by tests.

For 4503599627370497, expeced answer is -1, because it is not a perfect square (but 4503599627370496 is).
For 4503599627370495, expeced answer is -1, because it is not a perfect square (but 4503599627370496 is).

Solutions which cannot handle these inputs are buggy and need to be fixed, it is not a problem with tests.