Incomplete specification for run-length encoding?

[remcopeereboom]

Unless I'm mistaken, the tests for the run-length encoding problem don't account for numerical data. Single character sequences are not prefixed with a number and runs of characters are not prefixed with an escape flag. This leads to ambiguity when dealing with strings like these: 22333, which encodes to 22333, but what should it decode to: 22333 or (2233 * 3) or 2(23 * 3) or one of the other possibilities?

[Cohen-Carlisle]

The thought also occurred to me but I assumed it was intentional.
Perhaps a precondition of no digit characters should be explicitly called it if that is the case.

I'd imagine we could run into some interesting problems with the metadata otherwise as different languages may have preferred ways to handle this (multidimensional arrays vs tuples vs escapes in strings, etc.)

[remcopeereboom]

Perhaps a precondition of no digit characters should be explicitly called it if that is the case.

Really any choice is fine, as long is it's specified. That said, I'm not keen on not allowing numbers given that the code explicitly handles unicode characters. The simplest solution would be to also prefix single character sequences with a count of 1. That does tend to defeat the optimization in most practical applications, however.

[Cohen-Carlisle]

Wouldn't including 1s still not solve the problem of numbers? As per your example: 2233 is ambiguous: is it "233" * 2 or "33" * 22, etc. I like the idea of simply calling out that the approach currently outline only works on inputs without digits.

[remcopeereboom]

Yes you are completely right. I missed that.

[behrtam]

I think adding 1s (always the count) and limiting it to max chunks of 9 would solve the problem, because you would get a clear pattern of count/character. So 2233 would always decode to 2 * '2' + 3 * '3' => '22333' but you would also get encode('11') == '1111' and if you get more that 9 consecutive chars that are the same, it get's quite complicated '9W3WB9B3W3...'.

There are already 9 tracks that implemented this exercise without 1s, so maybe the easier way would be to change the readme instead of all the implementations.

[Insti]

I think that in order to keep the exercise simple, it would be better to not include numbers.

Explicitly mentioning that it only needs to handle letters in the Readme is probably a good idea.

Here is the description.md

[robkeim]

I just sent out #530 with the clarification on the simplified input as @Insti suggested.