Ad
  • Custom User Avatar
  • Custom User Avatar

    all suppliers need to have a different price

    Reference solution violates this constraint in even the simplest case:

    demand: {{"1", "1.20"}}
    supply: {{"1", "1.20"}}
    capacity: 1
    expected:<1.20> but was:<1.19>
    
  • Custom User Avatar

    Random tests are setting 1 test block per random test and creates many duplicate methods per random test case. Why not just use a for loop?

  • Custom User Avatar

    Some tests are supplying prices with incorrect scale and sort of expect solutions to fix them, such as:

        @Test
        public void sameResultWithDifferentPrices() {
            String[][] demand = {{"75", "15.00"}, {"50", "16.00"}, {"16", "25"}};
            String[][] supply = {{"100", "12.50"}};
            pickYourPrice(demand, supply, "25", "25.00");
        }
    
  • Custom User Avatar

    There is a conceptual problem with the kata: the kata asks us to find the outline, which is defined as

    The outline is the sum of the three sides of the outer triangle

    And the reference solution assumes that the outline is a triangle, and calculates the two sides accordingly. However, the two sides of the triangle are not straight lines: they are triangle sides displaced vertically by card width. The actual outline is hence all the card width and card thickness combined, not a straight line from the apex to the two corners. This is very obvious once card thickness becomes comparable to card length.

  • Custom User Avatar

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

  • Custom User Avatar

    The current Elixir reference solution (brute force) is not viable. It times out before it can complete a single edge case such as (4987653201,20), or (2987654301,10), etc.

  • Custom User Avatar

    Finding the number of elements in an arithmetic progression based on its sum is not new.

  • Custom User Avatar

    Nice kata. A couple recommendations:

    • increase the number of random tests to something like 50 or greater
    • add additional fixed edge cases like (4987653201,20)

    When I initially approached this problem, I misinterpreted offset to be n-th iteration, rather than starting from the value >= offset. The Description is fine; I just misread. I bring this up to gauge interest in a kata similar to this, but where offset refers to the n-th iteration offset.

  • Custom User Avatar
    Returned price doesn't match expected value.
    

    It does not help to debug
    Please use assertEquals([message ,]expected, actual) instead of assertTrue...

  • Custom User Avatar

    Sample Tests expect wrong results

    BigInteger.valueOf(3), BigInteger.valueOf(4)), new BigInteger[]{BigInteger.valueOf(2), BigInteger.valueOf(4), BigInteger.valueOf(32)}
    
    3/4 != 1/2 + 1/4 + 1/32
    
    BigInteger.valueOf(4), BigInteger.valueOf(6)), new BigInteger[]{BigInteger.valueOf(2), BigInteger.valueOf(6), BigInteger.valueOf(72)}
    
    4/6 != 1/2 + 1/6 + 1/72
    
    
  • Custom User Avatar

    Tests expect BigInteger[] but initial code is public static List<BigInteger>