Implicitly added the formula into the description, so now you don't necessarily need to go to Wikipedia for the formula.

Pretty challenging to figure out, it takes a while.

Why did you mark it as a issue? It should be suggestion not issue

replaced with basic (not sure what base would mean here: a lame base sorting method...)

Fixed now.

Did I forget the sample tests?

Sample tests should use strictEqual.

This might increase difficulty to the point where the current average voted rank is no longer accurate.

10 000 is not enough. My original JS solution now fails, but if I rewrite it in fat arrow notation it intermittently still passes. The description says it shouldn't.

Optimising or memoising makes it pass within a second, so there's margin to bump the tests to maybe 20 000 or so; that should be enough to time out naive solutions.

I've implemented @JohanWiltink's updated version for this one and I've increased the bound to 10000 to make up for the optimized test cases.

As for Haskell, I know little about the language, but it seems that the difficulty level without any changes to the test suite is roughly similar to the updated JS version. But it might be worthwhile to just check once more to ensure consistency.

I have implemented the update and have also increased the maximum bound for JS to 10000 (the lower bound is still 1000). This does increase the difficulty of the kata very slightly for JS, failing some less optimized solutions.

On another note, I've left the Haskell tests as is (still 1000 to 7500) since increasing the bound does fail the sample solution; what will the necessary optimizations be in order to ensure that the tests are consistent across the two languages, or will it be better to keep the Haskell version as is?

If you document what you change about the JS tests, I can change that for Haskell; I'm still here ( though note I won't get notifications for this thread ). But Haskell tests are already much more optimised than the ( pre-above-update ) JS tests ( and do not crash on null like JS ).

JS Update

• Anticheat fixed tests were not running because they were in a describe, not an it.
• check was actually anti-optimised
• anticheat would crash on null
• .. and give useless feedback
• assert.equal would not dinstinguish between null and undefined

This update messes with performance requirements, because the test suite itself takes less time ( by quite a bit ). But I think it's worth it. You may want to boost the 7 500 a bit. Even without the unspeakable optimisation, memoisation will make solutions breeze through numbers up to 35 000 ( numbers between 35 000 and 40 000 may result in stack overflows though! ). 10 000 should be doable with just the ordering optimisation. Or you can just do some testing with the top-voted solution I guess.

some languages do, some dont. re-raising here with a list of affected languages

Those are just some names I gave in the description to describe the requirement in words; they are not code fragments so language conventions don't apply.