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?

Python and potentially other languages: description should be in snake_case.

Issue unclear. Resolving.

Also, 106 people have completed the kata already, so the description is fine.

Description should be language-agnostic (e.g. Python desc. should not be written in camelcase).

Hi,

Firstly apologies for underapproving.

As I was approving the kata I felt a bit of ambiguity when doing so - part of it did not feel complex enough to be a 7, but some part of it did.

If approving according to the average is the convention I'll try to follow that unless there's a visible problem with the community vote (such as random 1kyu voters).

Updated further with grammatical/formatting fixes (as suggested by ejini).

Fixed these among other grammatical/formatting issues within description.

Python: Updated to 3.10

The kata's performance requirements are drastically different. For example, an O(N) solution in JS would pass easily but would time out in Python.

In JS, the maximum input caps of at 15 while for Python it can go up to 10e16 (or something along those lines). This is more than enough to warrant a big difference in performance expectations.

IMO we should look at how many 8/7 katas we have already, do we really need more?

Basic manipulation of numbers is not a novel idea.

Returning multiple data types is bad practice.

1000 test cases is way too excessive (at least in Python).

Raised as issue