Yes. But in real life, oftentimes in production code this explicity becomes valuable.

The author's solution avoids O(N^2) complexity and that is what's really great and clever.

Yep, that's what I figured out at some point, see two solutions bellow.

Still occasionally getting overflow inaccuracy errors.

pc - 1 === pageIndex ? this.len % this.ipp || this.ipp : this.ipp

You're sure about that? Given the definition of weight :: String -> (Int, String)? (comparing weight is the same as your cmp)

Column 8 contains 3 twice and is missing 5. Column 9 contains 5 twice and is missing 3.

If you think that the tests are broken, file an issue. Somehow, I didn't get notified on your comment, I can have a look at all issues/suggestions/questions other's have posted on my katas.

That being said, in which language did you try to solve the kata? And could you share your code (properly formatted and marked as spoiler)?

Good comment. Ideally there should be an RE escape function (to the concatenation specs of Kleene algebra) mapped over each of the keys. You would probably see that from my solution if it was a language feature.

You can consider it to be a requirement of the function that all of the object keys already adhere to concatenation specs (which at least fits with the test cases). From the kata description there's no requirement on what the key values can be, but with most parsers there's usually a limited set of characters you can use. Javascript, meanwhile, is a great example of not following this generality since you can plug plenty of Unicode characters into variable names.

That fixed it, or at least my last run didn't hit any errors about being off by just a digit or two. Thanks.

They can't. This seems like a wrong test.

I think we need some tolerance for error for the test cases with large numbers. Since the calculation is done in floating point, the result will depend on the order in which the math is done and so expecting equality is unrealistic.

Sounds like a string vs number issue. JavaScript?