Check what happens when you try to round following numbers: 2.5, 3.5, 4.5, 5.5.

I'm sorry I don't understand what you are both saying, about nearing to the "nearest even integer" (it's probably because of my lack of mathematical knowledge).

In Python, as far as I know, if you try to round let's say 4.6, it will give you 5, which is the "nearest integer" (not even), just like it's specified in the statement.

What am I missing?

Well, exactly this is the case when &Vec<Vec<>> is better. I've started with

type Matrix = Vec<Vec<i32>>;

but then decided not to overcomplicate the code. We have a matrix type here, represented with Vec<Vec<>>, not an arbitrary slice of Vecs.

Also, there's nothing wrong with negatives in matrix, they should be allowed, but I don't see any actual reason to test them.

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.

Added better diagnostic messages.

Fixed the incorrect function definition in solution setup.

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.

this is now untrue, isomorphism is available :) https://www.codewars.com/kata/isomorphism

Should be marked as resolved

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.

fixed

• 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.

Yeah, I wanted to avoid overflow, but that didn't work. Thanks for catching that.

I've tried your suggestion, but b ended up as 0 or 1 in most cases.

I've also added assertion messages.

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.