Round to 2 decimals.

This is not enough information. In addition to the required precision, the kata should also specify the rounding method (e.g., half-to-even), and when to apply the rounding (e.g., on the sum at the end).

Thanks for bringing this to my attention. I agree they should be treated as integers, but IIRC six years later, at the time the solution tests didn't treat them this way.

Marking resolved.

Python

Correct solutions show red on the Array = portion of every random test. The Command = portion shows correctly. Example:

[Open Red/Error/Down Arrow] Random Tests
    [Open Red/Error/Down Arrow] Array = [37, 13, 1, -1, 40, 45, 53, -3]
    [Closed Green/Correct/Right Arrow] Command = >>

Fixed test error messages are wrong and inconsistent.

The first error message says the initial number is 7 but it is -7. Tests 2 and 5 only provide the results and not the initial conditions.

Beautiful and fast solution.

Just to expand on this a bit for those who don't know, there are many issues with rounding and computers.

The three most relevant here are:

1. Floating-point representation: Many decimal numbers cannot be accurately represented in binary, so the number you see on the screen is already an approximation of what is actually stored and operated upon.
2. Different rounding methods: Some methods round .5 up, some round it down, some round .5 to the nearest even integer (as mentioned by @awesomead). (There are also many other methods although we don't always think of those as rounding---e.g. rounding towards zero, which is like floor, but rounds negative numbers up towards zero rather than down so that their absolute value matches their additive inverse).
3. Different libraries and modules often use different (or configurable) rounding (and someone trying to optimize their code might pick a different path than the author did).

What this means practically for kata is that without a clear definition of what it means to round, it can become a game of 'guess how the kata author rounded' and become a problem to debug both kata solutions and the kata itself.

FWIW, Python's builtin round rounds .5 to the nearest even integer by default (with ndigits = 0 or ndigits = None). With ndigits > 1 it looks to the digit to the right of the 5 to decide how to round, but because of (1) above, it can appear random or arbitrary.

One solution to this problem is to not check for exact answers, and instead include a fudge factor:
assert abs(actual - expected) < fudge_factor.

h = 1955
Incorrect answer: [[1952], [2]] should equal [[1950], [1308]]

Random tests or spec solution in Python is bugged. 1952 has an abundance of 2, is greater than 1950, and is in the interval [1, 1955].

All numbers are equal except for one.

All programs have constraints on input. In this case, there can only be two distinct values in the array. We can certainly program a solution to return an array of any number of unique values; but that's a different problem and the solution to that problem will be less efficient when applied to this problem.

To my knowledge, the only time math.sqrt would be faster would be when you're doing a large number of square roots. Probably more than you'll see in a kata (but don't quote me on that one).

Generally I don't worry about it unless I'm doing something that is centered around a lot of square roots and I'm having issues with optimization. If I do worry about it, I have to test it anyway.