fixed

Useful to know. Thanks for clarifying the meaning of this RegEx.

Raised as an issue.

Absolutely! :-)

Let me know if it's okay as is.

I've also updated the Rust version to 1.49.

Have a great day.

Why your solution with recursion is twice faster than with linq query?

@ewingsa, I've removed the todo comment and extra space.

Regarding the random tests, please see my reply in the C++ discourse. Thanks.

@ewingsa, I removed the todo comment.

Let me explain the random test algorithm. I used this same approach for the C translation. In your Java and JavaScript versions, you call testDimension() for each of 5 different ratios. For each call, you test 20 random widths, for a total of 100 different trials. What I did was spin through 100 trials, randomly selecting one of those 5 ratios and a width for each trial. So the total number of trials is the same, and there is a statistcally even spread across the 5 ratios, but it's all randomized.

The two lines you list above declare an array of the 5 preselected ratios as strings, and then declare a function that generates a random index for that array. There's a second array of the same ratios, but stored as integer pairs rather than strings. This saves me a couple string to integer conversions. So for each trial, I randomly generate a width and a ratio index. Then I pass that width, indexed ratio string, and generated result string to the test function.

It doesn't matter here.

Thank you for the feedback. I really appreciate it.

I have just added your "basic tests" to the Sample Test Cases and to Test Cases.

Approved, thank you

While it's true that this could be approximately twice as fast, the complexity is still the same (constant factors are ignored).

The "norm" is usually 50-100 random tests, unless it's a performance kata (which this is not).

please fork it. I dont mind.

May I suggest you improve existing versions first?

If and when this starts getting good votes and decent ratings, I'd like to contribute a Haskell translation. But it needs to show it'll survive first.

Please get rid of the input validation, please implement random testing, please specify a performance requirement ( it need not be restrictive, but it would sure be nice to know that in advance ).

Sure, but if best practice was my goal here I'd change a dozen other things as well...