Ad
  • Custom User Avatar

    Approved by someone.

  • Custom User Avatar
  • Custom User Avatar

    It is fine to have a simple message for large tests.

  • Custom User Avatar

    Potential solution to the point above is to generate diffs, though those could still pretty easily overflow which is why I didn't.

  • Custom User Avatar

    Fixed.

    The large random tests have rather nondescriptive assertions now but I can't forsee that being too much of an issue with the small ones present.

  • Custom User Avatar

    Small random tests must be added (100 tests with sizes 1 - 10). And there should be a custom error message for large random tests. Currently, failed large test cases output more than 1.5Mb of text and cause an overflow.

    Small random tests reveal a flaw in the random test case generation algorithm.
    4 lines following the comment # Place a 1 on each edge to force the location of the bounding box should be executed after 3 lines following the comment # Fill the bounding box with stuff. Right now, random values in the loop could overwrite previous values.

  • Custom User Avatar

    Marking as resolved following the merge of fork with suggested changes.

  • Custom User Avatar

    Thanks for the feedback and the suggested changes - I have merged the fork with the suggested changes.

  • Custom User Avatar

    Fork implementing these suggestions, reduces maximum runtime from ~9 seconds to ~2 seconds whilst maintaining current specifications.

  • Custom User Avatar

    Funny kata to practice and exercise with.

  • Custom User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Random tests should be made smaller and more consistent in run time. There's no good reason why a non performance kata should have an 8 second run time with the authors solution. Conversely, if this is intended to be a performance kata, then the tests should be tuned for more consistent run times - currently our solution varies randomly between 3 and 7 seconds of runtime.

    If you just want to time out solutions worse than O(mn) or so, then even 1/10th of the input sizes will achieve that whilst also massively improving user experience.

    Also, having smaller random tests for debugging purposes for the user would be an improvement.

  • Custom User Avatar

    Thanks - typo now fixed!

  • Custom User Avatar

    Typo in description:

    ... and the interior is filled with 0s retruned in an array of the same size as the original

  • Custom User Avatar

    Should be resolved now. Thanks for reviewing

  • Loading more items...