although this comment helped me, it still does no fully describe the actual criterion, which is really hard to deduce from the description: if a prime permutation is above n_max, it does not count towards k_perms and the initial number is still a valid candidate. for example for n_max = 2000, k = 1, 1979 is a valid solution because it has a single prime permutation <= 2000, that is 1997. This is despite the fact that there are other prime permutations of 1979 that are above 2000: 7919, 9719, 9791

1. If not stated, the area by definition is always the positive value, and the sides are undirected, so it's not required to specifically note about absolute area. (Otherwise yeah, the area might be negative in some circumstances, but that's an overkill imho)

2. Probably that was because of some shenanigans with assertions; rn both 3.10 and 3.11 correctly evaluate either float or int values, so it doesn't really matter to specify that either.

Hope I've answered your suggestions, closing this now

approved!

i substantially improved the RNG in Python

Not really an issue, no performance tag, no explicit mention of large arrays. A performant version may be created but I doubt if it is any different than myjinxin's three sum and four sum kata (potentially others ... ->

• simple fun ? a + b + c
• simple fun ? a + b + c + d

Done

I saw SADS, but changed it to UNHAPPY instead :P

Seems unneccessary to mention the test parameters in the description as they both vary by language and have no performance constraints beyond what are provided by the sample tests.

The print garbage has been purged.

The spoiler flag XD

As far as I can tell it's all async in JS at least on newer Node versions.

I didn't know "it" blocks inside previous "describe" blocks were executed before the next "describe" block. Very interesting, and useful for other kata's.

I added using namespace std; to the test code. Now it is not required to add it to a solution.

.

Yes, there is no performance constraint whatsoever in other languages too.