This is kata creator fault .

Right now there is no clarification in description or test case for one particullar scenario - values with different types but with human equal values .

Solution of OP will fail such test case :
Assert.AreEqual(false, Kata.Check(new object[] { "66", 101 }, 66));

In real game/program such oversight could lead to nesty bug .

Given the constraints of the items being either a number or a string, there's no reason that this should fail the tests.

why?
i also did that way but it passed
could u say what is problem there?

Hmmm, I did try using a PriorityQueue instead of the dictionary, but it was hell to work around the duplicate entries issue, so I gave up. Wish I'd spotted that a SortedSet would give me the same functionality.

Exactly my thoughts right now :D

This shouldn't pass the tests.

Yes, it works for all but the edge case of just reaching, where the 2 * int + 1 counts that as passing the window, where the floor doesn't. Took me a long time to work out why that was the case :(

maybe because casting to integer floor the number rather than ceil?

replying to Jon - surely the int value of the character is the ASCII value?

M is -- and I is .., so I assume the M/I thing is the next test along failing after the E / T thing.

The instructions were to ignore leading and trailing zeroes. When you do that the time signature for the first one is singular, for the second it's tripled.

I'm sure it's clever, but it's beyond my understanding lol

Thank God someone else came up with the sensible solution. I was beginning to despair looking through these.

Best Of Breed after looking at some of the other solutions?

I didn't know you could pass Char.IsLetter like that, should have guessed since you can in Java. In Java, this is considered better practice, is it the same in C#?