Ad
  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    Added better diagnostic messages.

    Fixed the incorrect function definition in solution setup.

  • Custom User Avatar

    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.

  • Custom User Avatar
  • Custom User Avatar

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

    Should be marked as resolved

  • Custom User Avatar

    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.

  • Custom User Avatar
  • Custom User Avatar
  • Custom User Avatar
    • 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.
  • Custom User Avatar

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

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

  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    Fix

    • Add random tests
    • Add assertion messages
    • Add language specific block in description
  • Custom User Avatar

    Rejected, because:

    • No random tests
    • No assertion messages
    • No language specific block in description
  • Loading more items...