I don't really know how it worked but it did..

Bad description.

Duplicate issue.

First sample test makes no sense.

It does.

@freeman42x Integer division rounds down, which is needed anyway in the end. Intermediate roundings only slightly slow convergence. The main point is that every next approximation is closer than the previous and that in eventually stops.

@g964 Nvm, apparently it works fine regardless of using integer or floating point. Although I can't find good explanation on that.

@g964 using integer division is wrong, you should specify clearly in the description that the division should be floating point (or whatever non-integer division is called).
I see a mix of integer and non-integer solutions yet only the non-integer division ones should be valid.
All pass because the test cases are wrong.

Why is it slower?

[25,25,25,100... results in $100 in the clerk's drawer, but in the form of a $100 bill isn't useful for making change (unless someone shows up with a $125 bill :-) )

I don't want to argue once more but I think one should take (x + n / x) / 2 as a purely mathematical description and not as operations specific to a given language. If you look at the solutions (in Python or other languages) you will see that everyone has adapted this formula in his own way to get the result (Perl motto: There's more than one way to do it!). Nevertheless thanks for your posts!

That is an improvement. Technically, it still is ambiguous, since (x+n//x)//2 does not always give the same result as math.floor((x+n/x)/2). (i.e. Is n/x cast to integer, or just (x+n/x)/2?) For example, 24267650325993838580 not only converges one step slower for (x+n//x)//2 it doesn't even arrive at the same result as (x+n/x)//2. There are many such values, typically with true square roots very close, but not equal to integers. None of your test cases give different results for the two methods, though, so your updated language is probably good enough.

As an aside, I also notice that if you use integer division for both divs, there are some input values that will never converge to less than one. 120 is the first one greater than 100: (10+120//10)//2 = 11 ---> ((11+120//11)//2) = 10 There are ~300 below 100,000

Modified with "repeatedly calculating a new approximate integer value x using: (x + n / x) / 2" though the given examples show that at each step the new value is an integer.

Also, in JS / always means floating point division.

You can clarify it effortlessly by adding a tiny sentence in the descriptions while helping people doing the kata in other languages. Why not do it?

...but the algorithm provided (x + n / x) / 2 doesn't work in general - only in languages that interpret "/" as integer division, rather than the common meaning. What would be the harm in clarifying which version of division is being checked against? If you don't want to use the word "Python," how about "repeatedly calculating a new approximate value x using: (x + n / x) / 2; (Assuming "/" represents integer division.)"

The description is written for a lot of languages, not specifically for Python...

It is not clear that expected implementation of Hero's method is to use integer division. In Python 3, using (x + n / x) / 2 as in the description, the routine will fail in some test cases. Suggest adding to the description so that it reads "repeatedly calculating a new approximate value x using: (x + n / x) / 2; (Assuming Python2 integer division.)"

I hadn't read that line about math.floor, because it is preceded by "Note for JavaScript, Coffescript, Typescript...." Didn't know that there is information needed for Python solution also.