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

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

  • Default User Avatar

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

  • Default User Avatar
  • Default 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?

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

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

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

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

  • Default User Avatar

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

  • Default User Avatar

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