The comment was from before you changed it.
Still, no real solution would use more tgan one line, it's an unnecessary check that clutters the kata title.

Seems pretty different to me

Water always takes the path of least resistance, you have two options:

• Force it to go the way you want, by adding numerous restrictions.
• Make it so the path of least resistance is the intended one.

I used to make katas with lots of restrictions, I stopped because I realised that it was more fun to allow the user to do what they wanted.

I would remove the length != 2 tests, they are unnecessary and take away from the main goal of the kata, which is the performance tests. Should you keep them, at least have a test in the examples which covers it, at least half the users don't read the description and do the task based on examples (me).

Also, for a micro optimization kata, it's very important to include the bounds for the size of the input as well as the number of tests. Currently there is only the size. I'd would also recommend displaying this info in a code block, like you did for the examples, it's better for translations.

Furthermore, if you submit the solution without anything, you get a Buffer Overflow. This is because you are printing the expected string for every test, which is very big. You should only show the expected output in the smaller tests as they won't overflow the buffer.

The additional "x" is supposed to be there, you're the one that's not including it.

You should probably specify the input range, like, how big the string can be.

I don't want to start trying to come up with a fancy solution if brute force works.

Fraction(262125, 131072) should simplify to Fraction(2, 1) because the value is very close to 2.

No it shouldn't?

You are not supposed to calculate an approximate value, you are supposed to calculate an exact value.

This kata isn't about writing a simulation program, you're supposed to do some algebraic manipulation to come up with an exact solution.

You can throw the sum into WolframAlpha to get the expected value of a sum. You just have to write a program that replicates its results.

I agree that it would be better, but is it worth changing after this many solutions?
I'm willing to do it if you approve of it, though I may mess something up with Java.

Feels like a 2016 kata, lol

It really just comes downs to how confortable you are with mathematics. I'm sure there were many users that solved this in around 5 minutes. Personally, I found it a 6kyu.

Also, modern 3kyu katas are way, way harder than this. I published a 3kyu kata myself not long ago where the average solution has around 70 lines of code, this can be solved in one.

When Kayleigh said gmpy is too slow, they meant that gmpy2.next_prime is too slow.

You just presented the same sieving algorithm, using a different module.

If your vision for the kata is to generate primes "on the fly", then gmpy2.next_prime is the definition of fast JIT primes, if that doesn't pass, then there isn't much the user can do.

Python fork.

It's a bit jank and it uses some hardcoding on my part. It's still possible for the user to hardcode it, but it would be considerably harder.

If you implement a code length check, then it should be very safe, but you'd have to mess with the description. To be honest, that would probably be a good idea.

The Python version is all about knowing numpy, you don't need to deal with bitmasks or any proper optimizations. It would at least be good to warn users that try to do it properly.

I haven't seen any Python katas that stright up requires you to use numpy, at least not without telling you. I just don't think "know you libraries" fits CodeWars, but that's just personal preference.

"The others are just as bad" isn't an excuse. The kata as a whole has issues, it would be good to fix those before approving more translations.

Also, exploiting bad specs isn't cheating, if you don't want people to exploit the tests, then write better tests.