Most people will probably start from that approach, including me. That's exactly why the character threshold is set right below its length. If no minor "local" edit will shorten that approach further, you'll need to take a detour.

Approved by me, thanks for translating.

How about this:

1. In the test framework, precalculate a single massive lookup table (e.g., 50 * 10 ** 6 elements) using the intended optimal algorithm, taking around 5 seconds.
2. Instead of asking the user to verify the correctness of a given input, simply ask them to return a lookup table, starting with a few small ones to test for correctness, and then one with the full 50 * 10 ** 6 elements. If the user's algorithm is not fast, the final table generation will timeout.

Granted, it would essentially be another kata entirely ("Lookup Table For Paperfold Sequence"), but it would solve the precalculation issue.

Good catch. Can you switch it to relative (perhaps with a manual calculation)?

By the way, I tried approving your translation, but Codewars states Description cannot be approved, recent changes from related record must be merged first.

Oh, I see. At least in python, assert_approx_equals checks whether the answer is close with absolute or relative margin. By using a margin 1e-4, I intended that the user's answer should be within 0.01% of the reference answer.

I'm not sure how the equivalent Javascript assertion function works.

This was related to the int-vs-float return type issue. The description now makes it crystal clear that a full-precision floating-point answer is expected, and the reference expected results are full-precision floating-point numbers as well.

Thanks for translating. You are right, in the sample tests the expected results should be full-precision floating-point numbers such as 93278.32814049922, not integers such as 93278. This is how the random tests operate as well.

(Because of the type of mathematics involved, there will almost certainly be some discrepancy in the answers. For example, my reference solution to the first example is 93278.32814051147. This is why I chose the relatively lax 0.01% precision requirement.)

The intended solution is to return the result as a floating-point number without any rounding. I have updated the description to make this more clear.

I also updated the sample tests to have non-integer reference answers, in order to not send a wrong signal about the intended return data type.

Very nice kata, adds the desired layer of novelty over parts 1 and 2.

My submitted solution is not showing up on the "Solutions" tab, is this a bug in the CW system?

Are the numbers of marbles in urn1 and urn2 reported before or after the draw?