Whatever the clarifications will be, I suggest:

• either removing "for real" words in the task description, highlighting link to "k-means" algorithm and explicitly stating in the problem that k-means clusterization should be used here;
• or remembering Kotelnikov theorem and removing test cases which violate it - i.e., where sampling rate is lower than twice the transmission rate; the words Clearly 10 samples per second is enough resolution for this speed should be removed as well with the example around them, as not only that is not clear, that is plain wrong.

There is a test where "1001" (full string) should be decoded as "EE". Why not "I"?

00 could be treated as either 1 unit in length or 3 units. Why round up, instead of down, as in dot/dash ambiguity?

@geoffp. Oops. My bad. Thanks.

Thanks. The C++ translation seems to be OK now.

The new test case had a train "Bxxx"; I guess that was meant to be "Bbbb" and have changed it accordingly.

Thanks for additional info. I've added another test case (equivalent to your "simple test")

These translations are OK: C#, Java, Python, Ruby

This translation is NOT OK: C++

~

Unfortunately the person who created the C++ translation seems no longer active.
My C++ is rusty but I'll see what I can do about it.

EDIT: Fixed / Hacked? / Anyway, now C++ is working

Hmm, it seems that the Java and C++ versions of the kata are different in this respect. In the Java reference solution, the Train class has a variable

private int waitingAtStation = 0; // countdown to stop waiting

whose initialization to 0 will ensure that every train moves on the very first turn. (A separate boolean variable indicates whether the train is an express.) But in the C++ version this becomes

int turns_to_wait; // -1 if express

and we have the code

if (new_train.turns_to_wait != -1 && pos_list[train_pos]->station)
      new_train.turns_to_wait = 1;

so that newly-created non-express trains that start on stations have to wait one turn before moving.

A simple test that distinguishes these behaviours is (in C++)

std::string little_loop = "/-S-\\ \n"
                          "|   | \n"
                         "\\---/ \n";
result = train_crash(little_loop, "aA", 2, "Bb", 4, 100);

which should give the result 1 (both trains try to move to position 3 on the first turn). But the current reference solution in C++ gives 2 (the station delays the A train by one turn).

No no no. You are reading too much meaning into next and immediately ...

The rule is really simple:

If the initial train position (i.e. the engine) at the beginning of the "game" happens to be exactly on a station S, then the train will NOT wait at that station. Its first move will be to leave the station. i.e. The behavior of suburban and express trains is exactly same in such a scenario.

The "master" version (Java) of my Kata works correctly for this rule. I've added a new fixed test case to confirm it.

EDIT: Added new fixed test to all languages to check "Start exactly on the station" (for both suburban and express trains)

This tripped me up, too. When starting on a station, the train, if not an express, leaves at the next move, i.e. not immediately. But an express train ignores stations, so it leaves immediately. This implies that a non-express train that starts on a station will always be (at least) one step behind where it would have got to if it were an express. Unfortunately, there is no fixed test for this behaviour, but it comes up in the random tests sometimes.

Ah, sorry.

• Add JSON to the list of frozen modules. With the redefining of JSON.load credentials object becomes totally under control, and then it's easy way to all tests pass.
• The term "Metaprogramming" should be defined more clearly in the description.
• I didn't quite understand the tests. Do they check that any admin password is good, not just 'h4xx0r3d'?

That's specified in the notes:

If the start position happens to be at a station then the train leaves at the next move

I suggest to explicitly state that if a train is at the station at the start — it shouldn't wait.

Added in all languages.

Added a note in the "Language" section of the description.

It should be mentioned explicitly in the problem description that all calculations are to be made with floats, not integers.

It is reasonable to assume by default that "5 / 3 = 1", especially given that Ruby works in that manner.