A quick rundown of my solution versurs geoffp's:

• The base idea is the same: solving a linear system using all the given points
• Instead of a dispersion matrix, I derived a custom one (no idea if they're the same)
• Whenever sums of many elements are involved, the Kahan-Babushka-Neumaier algorithm was used to minimise sum error
  • In hindsight, I think the precision gained/error avoided was minuscule. But the algorithm is very easy!
• The given points are normalised against a bounding box (centre and scale), not centroid
  • I felt this was more balanced than centroid when too many points are clustered together, and scaling protects against under/overflow
• The system is solved by Gauss-Jordan elimination with complete pivoting, not Cholesky decomposition
  • I don't really know Cholesky decomposition, but Gauss-Jordan is both easy and numerically stable

Yes, but the code will never attempt to read it. That statement is in the if-condition, preceded by the statement "i < roman.size() - 1 && (...)". If the previous statement is false, the if-condition is "short-circuited", meaning the second statement is ignored.

I agree, this is not solved. I also had random test failures, and peeking at the first few values of the first "sorted" array in such random tests, I could find things such as: [290, 728, 75, 61, 341, 392, 361, 712, 973, 957, 866, ...]

I don't even know how my solution (or similar ones) passed with that. It did take me a few tries, at least.

The C++ starting function is erroneously and amusingly called PythagoreanTripe.

C++ extended test cases bugged - they don't include (but require) <iomanip> and forcs users to do it in their solution if they want to solve the kata. My solution, for example, never used <iomanip>.

Floating-point rounding errors.

w/(h*h) first multiplies h and then divides w.
w/h/h first divides w and then divides it again.

The different setup of the operations can introduce little discrepancies that mess with direct floating-point comparisons.

Your solution fails on that case because of a precision loss by the function pow().

The test expected 17 decimal digits, but pow() can only go up to 16 without precision loss, because it works on doubles (maximum 53 bits of precision). 2^53 < 10^17 so it can't fit in the result double of pow().

The starting code is odd, it's very C-like for a C++ kata. It doesn't work, either. And it's plain wrong - a parameter that should be some sort of range is instead a char reference!? Thankfully, that's no big deal...

A tip for other warriors: recursion too deep == SIGSEGV.

I had similar problems with C++.

The correct combination for me was floats for the calculations and truncated result.

These "guess what it is" challenges are nasty. Those who think they're as easy as other 7 kyu katas - beware!

For C++, the squares can be tricky because they don't fit on a byte. They can still be put on a string literal. Any string operations that assume "character == byte index" will fail on this string.