Ad
  • Default User Avatar

    to clarify: this only happens with the Cuban Peso (CUP) which has denominations [1, 3, 5, 10, 20, 50, 100]. all other currencies seem to be
    canonical

  • Custom User Avatar

    Should you have the notes of denomination 1, 3 and 5 available with a target of 6, there are two ways of making the total with the same (minimal) number of notes - 1 + 5 or 3 + 3. It appears that the tests only allow 3 + 3 and not 1 + 5 despite the same number of notes being used.
    Suggest that either the text specifies that the number of denominations should also be minimal, or the tests are altered to accept either solution.

  • Custom User Avatar
  • Custom User Avatar

    Got you, jpssj has fixed the Javascript version and I've added the same test case to the Python version.

    Marking as resolved but shout if you disagree!

  • Custom User Avatar

    Approved the change and added the same test to the Python version.

  • Custom User Avatar

    JS fork that should fix that issue, please review.

    • added the last example from @trashy_incel in the 'Special days' block.
  • Default User Avatar

    Yeah, sorry, I did not select my counterexample correctly. Here is one that hopefully works:

    friends = [ ["Alice", "2012-02-29"], ["Bob", "2012-01-03"] ]
    conversation date = "2016-12-31"
    

    Bob's birthdays:

    Thursday 3rd January 2013, Friday 3rd January 2014, Saturday 3rd January 2015, Sunday 3rd January 2016

    Bob's score = 2

    Alice's birthdays:

    Thursday 28 February 2013, Friday 28 February 2014, Saturday 28 February 2015, Monday 29 February 2016

    Alice's score = 1

    Bob should win, and that's what the reference solution says too. But my submitted code returns Alice, because it incorrectly counts her 2016 birthday as the Sunday 28th of February. In other words, the part of the description that says that we should take leap years into account for February 29th birthdays is not enforced, hence the issue.

  • Custom User Avatar

    Hi,
    29th Feb 2015 isn't a valid date so feeding that into the reference implementation would raise a ValueError. If I change your input so that the birth dates are in 2012 - the previous leap year, the reference solution returns Bob. Reasoning as follows...

    DOBs
    Alice : 29/2/2012, Bob : 5/5/2012

    2012 - Alice : Wed (29th), Bob : Sat (NB Birth years don't count)
    2013 - Alice : Thu (28th), Bob : Sun
    2014 - Alice : Fri (28th), Bob : Mon
    2015 - Alice : Sat (28th), Bob : Tue
    2016 - Alice : Mon (29th), Bob : Thu

    So both have one weekend birthday but Bob win as he is the younger.

  • Default User Avatar

    Friends born on 29th February celebrate their birthdays on 28th February in non-leap years.

    the emphasized part is not enforced, it is enough to just change their birthday to 28th.

    What is needed is a fixed test with a February 29th birthday and a timespan that includes a leap year such that the 28th was a Friday or a Sunday (e.g. 2016).

    Example:

    friends = [ ['Alice', '2015-02-29'], ['Bob', '2015-05-05'] ]
    conversationDate = '2016-12-31'
    

    Alice is born a 29th February.
    In the leap year 2016, the 28th was a Sunday, and the 29th a Monday. Since this is a leap year Alice's birthday is on the Monday 29th, and thus it does not count. She loses to Bob, because they both have 0 weekend birthdays but Bob is younger. My code wrongly returns 'Alice', the reference solution returns 'Bob'.

  • Custom User Avatar

    Missed tidy up! Started out with ENDPOINTS being a list of offset to apply to the start position, but then realised this would incorrectly include spaces that were reached from invalid intermediate destinations.

  • Custom User Avatar

    Struggling with rounding errors on this one, wonder if there is an underlying issue or a misunderstanding on my part.

    First example
    A piece of carpet 734.3m * 194.5m @ 820.7 per square meter = 117213481.945 round half up -> 117213481.95. Test expects 117213481.94

    Second example
    A piece of carpet 998.5m * 355.1m @ 63.1 per square meter = 22373199.785 round half down -> 22373199.78. Test expects 22373199.79

    Can't even explain it through the bankers rounding employed by Python's round() method. :(

    EDIT : Escalating this to an issue. If you look at my solution, https://www.codewars.com/kata/reviews/592c6d7c82de145d90000288/groups/65b0bd84ad28ac0001f1db6d you'll see two methods, cost_of_carpet and cost_of_carpet_MP. The only difference is the order of the operands in the multiplication and yet the results are different. The one with the MP suffix fails tests, presumably because of errors in the result of intermediate calculations. So, I think the tests should allow for this rather than expecting exact figures. And if exact figures are required, it would make sense to base the results on the outputs using the Decimal class to avoid these errors.

    Using one of the examples above and reoordering the operands...

    734.3 * 194.5 * 820.7

    117213481.945

    194.5 * 734.3 * 820.7

    117213481.945

    820.7 * 734.3 * 194.5

    117213481.94500001

  • Custom User Avatar

    Steve doesn't have 4 birthdays falling in weekends.

    (By the way : did you put the spoiler flag on your question yourself ?)

  • Custom User Avatar

    Steve have 4 birthdays falling in weekends, but Dave only 3. Why Dave is correct answer here?
    ("Steve", "2010-11-18"), ("Dave", "2010-11-22")], "2022-12-31") => "Dave"

  • Custom User Avatar

    .

  • Custom User Avatar

    Thanks both for the resolution, Christmas break meant I wasn't able to get to look at it.
    Happy new year!

  • Loading more items...