No. The output should be screen size, not the ratio. A 32x8 screen is not equivilent to a 4x1 screen.

MaxMatch starts at the first character of a sentence and tries to find the longest valid word starting from that character.

In the example provided, the results differ starting from the word them. them is a longer word than the, so them is expected to be selected as the longest valid word starting from the t.

You may want the algorithm to be able to distinguish that ["the", "middle]" make more sense than ["them", "id", "d", "l", "e"], but that is what the algorithm does. The kata is about coding that algorithm, not about segmenting the words as a human would expect.

Other languages do have fractional heights that need to be truncated! Look at all the other comments on this kata. This can be self-verified, too.

I am not changing the behavior of the existing languages! I am merely explicitly noting what that behavior is!

Hey, Chrono79, could you please weigh in on the recent issues that Unnamed has opened on this kata, and my replies? Thanks.

Truncating the height does not need to be directly tested, and already is the behavior for every other translation. Please see Chrono79's comment below. I am just explicitly noting something that I thought was understood implicitly, but based on other comments, seems like it would be helpful to add to all existing translations.
The difference between Rust and the other translations is only that it is harder to truncate the final result, while not truncating intermediate operations. Other languages do this more implicitly, but I do not think it does any harm to note the desired behavior explicitly.
I am going to mark the issue as resolved. If you think the note should be only shown for the Rust translation, downvote this comment. If it makes sense to show the note for all translations, upvote it. I will make the change according to the most votes tomorrow.

That combination certainly is possible. In that case, the appropriate result is 1740x489 since the real height would be 489.375.

I have added a note to the kata description saying that all fractional heights should be truncated.

I also updated the Rust code so the height is calculated appropriately. The results of intermediate operations should not be truncated, only the height result.

Approved!

Looks good to me. Approved!

Please have these be the sample test cases.

do_test(1024,  "4:3", "1024x768");
do_test(1280, "16:9", "1280x720");
do_test(3840, "32:9", "3840x1080");

I deliberately have different sample tests and basic tests. This is so users have the same, non-random test cases fail if they are coding against the sample tests.

Also, just for consistency, could you please change this line of the initial solution to be

todo!() // Happy coding :)

for consistency with the other versions?

Done.

Approved!

Excellent. And thank you for the thorough explanation! Approved.

Excellent! And thank you for the very thorough explanation!

Please remove the

// TODO: Replace examples and use TDD by writing your own tests

in the Sample Test cases, as well as the empty line below it.

Also please limit the number of random test cases to 20 to match the other translations.

Unimportant, but a moment of learning, could you please explain how the combination of these two lines work to make random ratios?:

static const string ratioStr[5] = {"4:3", "5:4", "3:2", "16:9", "32:9"};
static auto randomRatio = bind(uniform_int_distribution<int>(0, sizeof(ratioStr) / sizeof(ratioStr[0]) - 1), generator);