Ad
  • Custom User Avatar

    Hi @benjaminzwhite. Thanks for the feedback and pushing the process forward. I believe I have fixed both of those issues. If I misunderstood or there is anything else I need to change, let me know.

  • Custom User Avatar

    As an example, take layer 3 -> 4:

        1          1   
       2 2   ->   3 3  
      1 2 1      3 6 3 
                1 3 3 1
    

    If you overlay these on top of eachother and look at them from above, the elements in the higher layer (layer 3 here) will be located just below (from our perspective) the elements with the same position in the lower layer. For instance, the two layers above can be overlain as so (level 3 in italics, level 4 in bold):

              1
              1
           3     3
           2     2
        3     6     3
        1     2     1
     1     3     3     1
    

    From this, we can see that every element in layer 4 is the sum of the (one to three) elements in layer 3 that are immediately in the down, up-right, and up-left directions from a top-down view. These are also the three closest elements in the layer above.

  • Custom User Avatar

    Tested with naive solutions and should now work even without performance-minded solutions.

  • Custom User Avatar
  • Custom User Avatar

    The only alternative I have found is to check equality outside of the assertion and use test.expect(success, f"Failure at n={n})" instead of test.assert_equals(...). Is this considered an acceptable method?

  • Custom User Avatar

    I have reduced the expected range of random inputs and the number of random test cases, so hopefully this is fixed now. I will test some more with a naive solution to make sure that significant optimization is not required to pass. Thanks for the feedback.

  • Custom User Avatar

    Hopefully the first point is fixed now. Thanks for the feedback.

    Is there a better way to handle the buffer size issue here? The problem is caused by the assert_equals function printing the expected solution (which can be very long at relatively low input). I can't seem to find a way to prevent it from printing out the entire expected output and the best I've been able to manage is to cause early termination at any random test failure (by setting allow_raise=True in assert_equals).

  • Custom User Avatar

    Agreed. It was difficult determining for certain what was being asked for. I suggest something like the below wording at the end of the Task section:

    The function should return the minimum number of socks that must be pulled out such that you are guaranteed at least num_of_pa_want pairs (of size num_of_soc_in_pair) of matching socks.

  • Custom User Avatar

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

  • Custom User Avatar

    It is not clear from the description that the tests expect the output to be entirely lowercase regardless of the case of the input. I would suggest clarifying this in the description.

  • Custom User Avatar

    Sadly, not entirely. It is giving me the expected and actual outputs, but no inputs are being displayed.

  • Custom User Avatar

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