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.
Sorry, I misunderstood your first post. I thought you were saying the author should add a warning to the description that warns users not to print every input. I see now that you meant that the tests should not output the full contents of very large arrays.
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).
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.
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 represent2 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 forma cos^n(x)
. But theSinCos
format wasn’t clear to me at all. I eventually figured out it means the terms should bea sin(x)^n cos(x)^m
wheren + 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
withstaticmethod
makes no sense in Python. Just make it a normal function like any other kata. Theenum
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
andRandom Tests
, show the input ranges and the number of tests — that’s also a solid option.You sly cheater! 😜
But indeed, the test suite should be improved so that your solution is rejected.
Moreover, there are less than 81 valid outputs, this makes the problem worse.
This comment is hidden because it contains spoiler information about the solution
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.Is this for Python, I don't see such logs?
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.
Sorry, I misunderstood your first post. I thought you were saying the author should add a warning to the description that warns users not to print every input. I see now that you meant that the tests should not output the full contents of very large arrays.
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.
There are tons of kata which pass large arrays as inputs, are you saying this warning should be added to all of them?
Do not print the input and output to the console for arrays that are bigger than
1000
elements or such. It gives aMax 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.This comment is hidden because it contains spoiler information about the solution
Loading more items...