Oh, about that (I guess we're getting nitpicky): you never use negative numbers, so the type should probably be a u32 instead of i32. Also, I believe it's good form to use &[&Vec...] instead of &Vec<Vec...> as the parameter type, though that is obviously more for real world applications instead of kata, where the type is always a Vec.

Your assertions need proper messages to communicate to the user what the input and what their output was. You can refer to the tests in this kata for a comprehensive breakdown of recommended authoring practices in Rust.

I see you've authored a few Rust translations; may I suggest that you go back and apply this fix to all of them?

On a different note, the description is terribly JS/Python-centric, and could benefit from being made language agnostic (or by structuring properly with language blocks). Maybe you'd like to take that on as part of this translation.

approved.

Something about the kata has to be changed, because having three issues a week definitely is not a sign of a good challenge.

It calculated 1.5 issues/week. However, I probably, maybe, possibly, uncertainly, likely used intermediate fractions in calculating the average, so you might actually be right, or even more wrong, would have to ask the author.

Approved, thanks.

• Added a few more sample tests covering a wider spectrum of inputs.
• Made random tests use proper random numbers that will not overflow
• Changed assertion output to be as beginner-friendly as possible
• Changed solution setup. It now does not result in a compiler error (which would make this kata unique, since every other kata is required to have the solution setup compile out of the box), and instead produces incorrect values.

Indeed, I should have tested my suggestion before asserting that it actually works.

Anyway, I've forked the translation and changed a few things.

Can you explain the logic in the creation of max and min in the random test? To me, it seems like a particularly complicated way of writing 1 and -1, respectively.

If the point is avoiding overflow, I'd simply generated a random i32::MIN < x < i32::MAX, a random a <= x) and b = x / a.

Also, this kata really needs good, clear assertion messages.

Rejected, because:

• No random tests
• No assertion messages
• No language specific block in description

Added rust-specific info to the description.

Rejecting, because:

• The requirement about n<1 or not an integer is a typical relic from authoring in a weakly/none typed language like Python or JS. It makes absolutely no sense in a strongly typed language, where input types can't be arbitrary, nor can they accidentally be negative integers when u32 is chosen. Using u32 and ignoring the input handling, which is completely tangential to the task anyway, was the correct choice here.
• You completely changed the solution used, but this translation was authored by akar, and upon approval the solution will be published in his name; however, it now contains your code, not his. Please don't do that unless strictly necessary. The solution's performance is completely irrelevant (unless it's a reference solution used in test validation) and really not your concern.

No longer an issue.

There is no point in forking a translation just to update the original solution (which would end up published in the original author's name anyway). Especially when there are other things that actually need fixing, e.g. missing assertion messages.

Rejected.

Good catch. Fixed.

Also made a typo trying to type "typo".