You're right. I've changed the maximum number of random tests to 416. Thanks for the heads up.

In random tests you may ask for ExpSum(417), but ExpSum(417) = 18987964267331664557 > 18446744073709551615=2^64-1
You can't give right answer in Go for this test

merged description and approved

😁
dp? should be sp!

Yes they were. You keep changing other unrelated codeblocks and in the process introduce duplication and conflicts. I forked and fixed it myself. Approved.

I did what you said. Are the merge errors still present now?

No, that's not how to fix it. Someone else has published a translation that contains modifications to the description that your translation does not have. You need to fork the most recent translation, copy the description over into your translation, and then update with any modifications you want to add.

I've modified the URL of Wikipedia site. Does the merge error exist?

Approvable once you fix the merge error (the description has since been updated by another translation, you will need to pull it in)

Thanks for your suggestions.

I modified the assertion messages and made the assert_helper function accept two parameters (n and expected).

Ok. Finale notes:

• Custom assertion messages are appended to the default message without whitespace. Please begin the assertion message with a newline character \n for better formatting.
• It's generally not a good idea to have two places where the same value must be used. In your assert_helper function, you have actual, ret, n. Calling that then requires exp_sum(n), ret, n. Without careful diligence, it is easy to make one or the other n mismatch.
  To work around this, have your assert_helper function simply accept n and the expected value (which you call ret, but is usually called expected so other users can easily understand it). The assert helper function then calls the user solution itself to compute the actual value. This has the additional advantage of making fixed tests more readable.

Answers:

• If n is greater than 417, the result will run into a u64 overflow error.
• Because n is smaller than 417, the solution of O(n²) doesn't take a long time.

Notes:

• Please add todo!() to the solution setup so that it compiles as is (remove the redundant comment)
• Add assertion messages that clarify what left and right refer to.
• Is there a reason for the specific number 417?
• Might a more performant reference solution be implemented (not O(n²)) to take less compute time from the user?

approved

I have removed the comment.