I get what you’re saying, but I think you’re kind of missing the point I was trying to make.

This isn’t about ignoring mathematical notation or pretending clean formatting isn’t useful, I like math as much as the next person. It’s about keeping the math part and the formatting part separate. In pretty much any computational math task, you first work with a structured representation of the expression, something like a list of terms or a tree, because it makes the logic clearer, it’s easier to test, and you can focus on whether your math is actually right. The nice, clean string is something you format later once you know your data’s correct. Mixing those two in a kata like this makes the difficulty feel artificial because instead of testing your math, you end up debugging string formatting.

By your logic, though, every kata involving polynomials should return strings, because 3x^2 + 2x + 1 is more readable than [3, 2, 1], even though everyone’s going to be using a list of numbers in their implementation anyway. Or in a 2D pathfinding kata, we might as well have people return ← → ↑ ↓ strings instead of a list of coordinates, since it “looks better.” Or if a user builds a heap, let’s have them return an ASCII art tree instead of a list of numbers. Sounds a bit silly now, right? But that’s exactly what you’re suggesting here.

This isn’t about “screwing the system” or writing math like it’s the XVI century. It’s just about good problem design.

Also, yes, the Binomial Expansion kata's main difficulty comes from the string formatting. However, that kata is over a decade old and was one of the first ones to have this kind of formatting requirement, making it a novel challenge. Nowadays, it’s just a matter of copy and pasting an old solution.

Look, if you think that the sequence of triples is too unreadable, the author could provide a utility function that formats the output as a string, like format_output(triples), which would return a nicely formatted string. That way, you can still focus on the math without worrying about formatting, and you can use the utility function to get the output in a readable format when needed.

The user solution is called twice per test on the random tests. This is both unnecessary and confusing for the user. Just save the returned value to a variable, then do your thing.

Honestly, I'm not even sure why you're doing all this number_of_true and number_of_false stuff at all, just do for _ in range(150) and you'll get the same result.

Also, the tests should providee a helpful message upon failure, use a message like Solution failed for input=<serial_number> or something similar, rather than just Rogues succeeded.

This kata's difficulty feels a bit artificial.

The whole "formatting the answer" part seems completely unnecessary for a mathematics kata. A formatting kata is cool, and a maths kata is cool too — but not both mixed together. What’s wrong with just returning a sequence of triples, like [(2, 3, 4), (-1, 1, 1)] to represent 2 sin(x)^3 cos(x)^4 - sin(x) cos(x)?

On top of that, the meaning of the formats isn’t properly explained. It’s pretty clear that the Cos format means the terms should be in the form a cos^n(x). But the SinCos format wasn’t clear to me at all. I eventually figured out it means the terms should be a sin(x)^n cos(x)^m where n + m equals the multiplier, but the user shouldn’t have to guess that — it should be explicitly stated.

Also, regarding the Python version: while I get that it’s trying to stay faithful to the original, using a class with staticmethod makes no sense in Python. Just make it a normal function like any other kata. The enum part is fine, though personally I think having two separate functions would make more sense.

Lastly, since you mention performance in the description, you should give the user some indication of how many tests there are and how big they get. This could be in the description itself, in a code block that changes per language, in the solution setup via a comment (which I personally like), or even directly in the test names. Instead of just Basic Tests and Random Tests, show the input ranges and the number of tests — that’s also a solid option.

Yes, this is regarding Python. Just have a solution like jump_to_zero = lambda x: x and hit attempt. It will reach max buffer size.

I agree with B4B here, I couldn't solve it until I ran the random tests. The Basic Tests were a plain waste of time.

Though, to be honest, I never enjoy these "Thinking and Testing" katas.

Oh, I understand. No worries my wording could have been better.

Yeah, that warning would be very unnecessary. What the user does is their problem.

Yes, I do believe that ideally every Python kata with large arrays as input should hide them when they are too large. Of course, it's difficult to fix every single one of them, but that doesn't undermine the concern.

If you wish, you can look for every single kata with this problem and leave this same issue there, I believe my point stands.

Do not print the input and output to the console for arrays that are bigger than 1000 elements or such. It gives a Max Buffer Size Reached (1.5 MiB) and makes it impossible to debug and check the sizes of the lists that are being passed (this should be in the description).

You can fork the JS version

There are many problems with the current JavaScript version. I believe it would be better to fix those issues before making any translations.

For instance, there are no random tests in the JS version.

Also, your translation tests : and ; as punctuation, while the original doesn't. I'm not saying that yours shouldn't, but it would be better to add it to the original one before approving this translation.

On the translation itself, please don't create a test.it block for every single test, this is ugly, messy and slow. Group many of them into a single one and only display the input if the user fails the test.

First of all, this is not an issue, but rather a suggestion. If you still believe that this is a valid suggestion, please create another comment, tagging it as such.

Now, personally, I believe there's no need for a hint here. The user could either use mathematical reasoning to come up with a solution, or they could brute force the solution for smaller numbers and infer a pattern from that (which took me about 3 minutes).

For Python, at least, you need more random cases for length == 4.
This solution
cannot handle such case, but still passes the random tests, given enough tries.

I guess I misunderstood what @dfhwze was doing in the tests. It should be fixed now, I edited it directly into the kata.

Should be fixed, I forgot to change the fixed tests and only changed sample