My python code is passing all tests, but times out in the performance section after about 190 tests. I have tried different approaches and on my laptop the code executes in less than 0.1 seconds for arrays as large as 50000 and numbers in the array as large as 1000000. I am struggling to find a more efficient solution. Any one can give me a pointer? Thanks.

Someone should rewrite the description of this kata. I see many complaints below pointing out that the algorithm is incompletely specified.

This is what the description should have said:

Choose any two array elements X[i] and X[j] with X[i] > X[j]. Set X[i] = X[i] - X[j].

Repeat until no more subtractions are possible (because all array elements are equal).

It can be shown that whenever there is more than one possible choice of the pair i,j, it doesn't matter which pair you choose: the answer will be the same in the end.

Before to even be a programming challenge, this kata is a total riddle as for directives.
Reading if X[i] > X[j] then X[i] = X[i] - X[j], one expects a left to right parsing, and only for immediate neighbour. But then one has to decrypt the example. Let's try with arrow in other direction:

X = [6, 9, 21]
X_1 = [6, 9, 12] # <- X_1[2] = X[2] - X[1] = 21 - 9
X_2 = [6, 9, 6]  # <- X_2[2] = X_1[2] - X_1[0] = 12 - 6
X_3 = [6, 3, 6]  # <- X_3[1] = X_2[1] - X_2[0] = 9 - 6
X_4 = [6, 3, 3]  # <- X_4[2] = X_3[2] - X_3[1] = 6 - 3
X_5 = [3, 3, 3]  # <- X_5[1] = X_4[0] - X_4[1] = 6 - 3

It seems we first substract 2 from 3, then 1 from 3, then 1 from 2, then 2 from 3, but lastly we substract 2 from 1. Not left to right, not immediate neighbours, so what? Deep right to left parsing? Greater from next greater? Greater from lower? Strictly none of those. Let's assume it's a deep right to left as far as possible then ending as possible. But what if [21, 9, 6]? Plus three poor test cases, can't help a lot.

I really like puzzles, and this one could be great as a puzzle if it was clearly stated. If it's not a puzzle, then some things should be clarified, as a lot of people already noticed in discussion. Personnaly, I feel that tagging it as puzzle and replacing misleading instructions with some more examples/tests, would been more interesting… Then one can try it only when in "puzzle solving" state of mind.

I am coding in golang and I pass every test case other than the "Input Mutation Test". I don't understand what this test is looking for/doing? The instructions don't say anything about this test case?
Here is what the console spits out:
Input mutation test
Solution changed input
Expected
<[]int | len:7, cap:7>: [1, 1, 1, 1, 1, 1, 1]
to equal
<[]int | len:7, cap:7>: [1, 1, 2, 2, 2, 1, 1]

The description is too vague to be useful and needs to be clarified.

Great fun! Please improve the description though, it's not immediately clear what you want us to do.

Could someone give a more clear description of this kata please? I might just be dumb but the one the author gave is really confusing me and I'm having a hard time getting started on the kata.

NASM translation

C++: tests can generate inputs for which result overflows unsigned long long.

This was a fun kata, thank you. I have to say however that I was almost turned away by the description, which in my view needs improving.

Indexes i, j are used without being defined. Also the part where the transformation example is presented could be more clear. I suggest to add X_0 [6, 9, 21] at the top of the sequence roll out, otherwise people will continue to think 12 is a typo instead of the result of 21 - 9.

Correction: upon further reading I see that there are no transposed digits but the whole text is somewhat misleading

I'd expect to have the

• input in the first line, followed by the appropriate calculations,
• the first result in the second line
  and so on.

Python: The description and example contain two pairs of transposed digits ( 21 <-> 12)

• description: The text states "...of the elements of input X = [6, 9, 21] is detailed below:" but the code starts with X_1 = [6, 9, 12]
• example (in essence the same): we call solution([6, 9, 21]) #-> 9 but the detailed steps start with [6, 9, 12]

The code shown assumes the correct values

Incorrect test structure in Crystal: "Basic tests" are not in an it block.

Not fixed. The random tests in Crystal sometimes crash with

Arithmetic overflow
/solution_spec.cr:20:16 in 'sol'

Tried testing with only returning a number, resulted in 4000+ ms, add 2 more lines, resulted in 7000+ ms, is this normal?