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

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

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

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.

Given the usage case, it seems totally reasonable to have an empty "histogram." The image could have a huge, scary black bear halfway out of the shot on the left edge - then there is no white rectangle in which to place text.

I am seeing the same result as Arcuo. Hero's Method converges in 29 steps for the input parameters given in that test. I printed out each step and counted them. I double checked this with excel. If the five of us who are getting 29 were instead writing code that converged too slowly, I would think we are doing something wrong. As is, we are converging faster than others, and I cannot see how we could be incorrect.

Iteration	 n 	              x 	                     newx	                 error after this iteration 
 1	 835,871,232,077,058 	 1.0                    	 417,935,616,038,529.0 	 417,935,616,038,528.0 
 2	 835,871,232,077,058 	 417,935,616,038,529.0 	 208,967,808,019,266.0 	 208,967,808,019,264.0 
 3	 835,871,232,077,058 	 208,967,808,019,266.0 	 104,483,904,009,635.0 	 104,483,904,009,631.0 
 4	 835,871,232,077,058 	 104,483,904,009,635.0 	 52,241,952,004,821.4 	 52,241,952,004,813.4 
 5	 835,871,232,077,058 	 52,241,952,004,821.4 	 26,120,976,002,418.7 	 26,120,976,002,402.7 
 6	 835,871,232,077,058 	 26,120,976,002,418.7 	 13,060,488,001,225.4 	 13,060,488,001,193.4 
 7	 835,871,232,077,058 	 13,060,488,001,225.4 	 6,530,244,000,644.7 	 6,530,244,000,580.7 a
 8	 835,871,232,077,058 	 6,530,244,000,644.7 	 3,265,122,000,386.3 	 3,265,122,000,258.3 
 9	 835,871,232,077,058 	 3,265,122,000,386.3 	 1,632,561,000,321.2 	 1,632,561,000,065.2 
10	 835,871,232,077,058 	 1,632,561,000,321.2 	 816,280,500,416.6 	 816,280,499,904.6 
11	 835,871,232,077,058 	 816,280,500,416.6 	 408,140,250,720.3 	 408,140,249,696.3 
12	 835,871,232,077,058 	 408,140,250,720.3 	 204,070,126,384.1 	 204,070,124,336.1 
13	 835,871,232,077,058 	 204,070,126,384.1 	 102,035,065,240.1 	 102,035,061,144.1 
14	 835,871,232,077,058 	 102,035,065,240.1 	 51,017,536,716.0 	 51,017,528,524.0 
15	 835,871,232,077,058 	 51,017,536,716.0 	 25,508,776,550.0 	 25,508,760,166.0 
16	 835,871,232,077,058 	 25,508,776,550.0 	 12,754,404,659.0 	 12,754,371,891.0 
17	 835,871,232,077,058 	 12,754,404,659.0 	 6,377,235,097.4 	 6,377,169,561.6 
18	 835,871,232,077,058 	 6,377,235,097.4 	 3,188,683,084.3 	 3,188,552,013.2 
19	 835,871,232,077,058 	 3,188,683,084.3 	 1,594,472,610.5 	 1,594,210,473.7 
20	 835,871,232,077,058 	 1,594,472,610.5 	 797,498,420.5 	 796,974,190.0 
21	 835,871,232,077,058 	 797,498,420.5 	 399,273,268.5 	 398,225,152.0 
22	 835,871,232,077,058 	 399,273,268.5 	 200,683,375.0 	 198,589,893.5 
23	 835,871,232,077,058 	 200,683,375.0 	 102,424,249.7 	 98,259,125.3 
24	 835,871,232,077,058 	 102,424,249.7 	 55,292,561.1 	 47,131,688.7 
25	 835,871,232,077,058 	 55,292,561.1 	 35,204,903.4 	 20,087,657.7 
26	 835,871,232,077,058 	 35,204,903.4 	 29,473,968.9 	 5,730,934.5 
27	 835,871,232,077,058 	 29,473,968.9 	 28,916,805.9 	 557,163.0 
28	 835,871,232,077,058 	 28,916,805.9 	 28,911,438.2 	 5,367.7 
29	 835,871,232,077,058 	 28,911,438.2 	 28,911,437.7 	 0.5 <<DONE in 29

Ugh. The instructions should be updated to explicitly state the intended output for an empty array (since it is expecting something that would normally be considered "incorrect.")

The very first edge case for Python is an empty array. There is no average for an empty array, and the description does not say what should be returned. NaN? Undef? (I really hope it isn't expecting 0!!)

Ok. This is the first time I have come across complex numbers in Python, so I learned twice here - Thanks!