[1,2,3] should be [(12-1)+n, (12-2)+n, (12-3)+n] <=> [0,11,10].
it's hilarious. from what we got 0.

T0I - an inversion of T0 - should be [11, 10, 9]. Note that if one asks for the TnI inversion of some set it means the inversion of the transposition n. Consequently, the TnI of [1,2,3] should be [(12-1)+n, (12-2)+n, (12-3)+n] <=> [0,11,10].

so let's take last one [7.4] with T0I
12-7+0 = 5
12-4+0 = 8. so what i'm getting wrong?

pcSet [ 9 ]
operation T1
answer [ 10 ] test says wrong

pcSet [ 7 ]
operation T9I
expected [ 2 ] to deeply equal [ 7 ]
12-7+9 = 14 % 12 = 2 so how we come to 7

pcSet [ 7, 4 ]
operation T0I
unsorted answer [ 5, 8 ]
answer expected [ 4, 7 ]
mind blowing

I agree ^^

Ok... Thanks, easy to solve knowing that indeed ;)
Description should really make it explicit.

It is not a chain of operations -> T11I is not T -> 11 -> I.
T11 -> Transpose by 11
T11I -> Invert by 11

My first impression was also that it was a chain and we would need to parse input like T3I5I11I5, but it is much simpler than that :)

I think Inversion process is not properly described:

[1,2,3], "T11" -> [0,1,2] (ok for me)

So, if inversion(I) subtract each element of the list from twelve., how would:

[1,2,3], "T11I" -> [8,9,10] ?

First:

[1,2,3], "T11" -> [0,1,2]

Then:

[0,1,2] -> "I" -> [(12-0)%12, (12-1)%12, (12-2)%12] -> [0, 11, 10] (sorted: [0,10,11], but no way to get [8,9,10])

Or not?

I would say that the description should still be revised to state that the inversion (if any) occurs before the transposition. This is important, because (12 - n) + m does not equal 12 - (n + m)

Oh no, the context is a good thing.

The revised description is better, and the idea I got from the old one wasn't crazy I see. :]

Done! Thank you!

I hope it is ok like this!

I noticed that I wrote this: "The function should return all twelve possible inversions." This doesn't make any sense. I wrote it for a previously thought problem... then I changed the code nd I forgot to delete that sentence. I believe that was the problem.(?) Regarding the context, I just thought that it would be more interesting to have it. Do you think it should be completely abstract? Anyway, thank you very much!

Thanks! It all makes sense. I will change it!

Rules, exceptions and examples are all thrown in together in a big lump of text. Not much structure.

Inversion is n => -n. Transposition is n => n + m. ( Everything modulo 12, but that can be done separately at the end. ) These can be combined. But being able to combine them means there is only one inversion, not twelve,; there are twelve transpositions though. They're independent. See my solution; I have separated the applications.

Looking at it as a programmer not being a musician means I look at the input and the output and find the structure that is there; I don't concern myself with sounds or any applied stuff like that. :P Sometimes that helps to make things simpler ( but doing it without concerning yourself with the application might lose things as well ).

Note on my solution: I think the .uniq in there isn't actually necessary. Also, I should have been working on a Set instead of an Array, but Set lacks a number of prototype methods that Array does have.

The function is just, well, a function. Obviously what you want is a function that operates on an array and return an array, and not a function that also processes input string. How the input/output are represented at both ends should not be the function's concern, or else the function is coupled with data format and it's not a very good design, so in real situations you'll almost always see the input become an actual array instead and the input processing logic extracted out as an separate function.

If they're returning the wrong thing and you're using the correct testing functions (i.e not Test.expect) then they'll see Expected: xxx, instead got: yyy, so the input feedback problem automatically disappears.