Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
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 becanonical
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.
.
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!
Approved the change and added the same test to the Python version.
JS fork that should fix that issue, please review.
Yeah, sorry, I did not select my counterexample correctly. Here is one that hopefully works:
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.
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.
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:
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'
.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.
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...
117213481.945
117213481.945
117213481.94500001
Steve doesn't have 4 birthdays falling in weekends.
(By the way : did you put the spoiler flag on your question yourself ?)
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"
.
Thanks both for the resolution, Christmas break meant I wasn't able to get to look at it.
Happy new year!
Loading more items...