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.

sometimes i wish i could just stop the likes of you from ever thinking about this (me crying abt my dogwater kata writing skills)

retired

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.

The Fraction function is not always returning a fully simplified fraction. For example, Fraction(262125, 131072) should simplify to Fraction(2, 1) because the value is very close to 2. Is there a way to round 262125 / 131072 to 2/1, since it's nearly equal? I do have a criterion in my code that stops the loop at a certain point(10**10).

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.

@lechevalier and I came up with a pure Python solution that passes the full tests. No NumPy, no gmpy2. Just over twenty lines, quite readable, nothing fancy. Finding the most efficient data types and iterators for the task took a bit of trial and error, but it's definitely possible.

I don't think that gmpy2.next_prime is a fast function. It returns probable prime numbers for sufficiently large inputs. By the same logic, BigInteger.nextProbablePrime should work in Java. Nevertheless, I agree that Python is not a good language for this kata. (Currently, the best available language is Rust.)

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.