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.

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.

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

734.3 * 194.5 * 820.7

117213481.945

194.5 * 734.3 * 820.7

117213481.945

820.7 * 734.3 * 194.5

117213481.94500001

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

Thanks for approving!

Fun Kata, although with a finger injury and dubious typing at the best of times, I lost count of the number of times I typed something less child friendly than "shift" :)

One suggestion, maybe a few more tests to make sure that shift, unshift and holdshift are only acted on when they are in square brackets, catching cases where brackets are stripped off prior to determining if the text in question is a command or not.

Cleaned up the tests slightly, but marking as resolved as the tests are no longer reliant on the preloaded dictionary.

Thanks Voile, updated so that the tests use a local copy of the dictionary. It's a copy / paste, seems a quick and dirty fix, wasn't sure if there was a "safe" point at which I could grab a copy of the preloaded dict before it could be altered..?

I threw in the towel and unlocked the solutions, and seeing other solutions I can understand where you are coming from. It's hard to classify what you might hint towards without spoilers, maybe an understanding of classes under the hood...?

Guess it's one of those things that you either you know, don't know, or know but not well enough to apply to the problem. I clearly didn't fall into the first category!

Interesting kata which I definitely learnt from, even if I didn't get the satisfaction of solving it.

Unless I am going off at a complete tangent by delving into how types work, I'd suggest that as a 6 kyu, this really ought to have some pointers on background reading to help people learn. Again, if my assumption holds, this isn't everyday stuff.

There's another instance to correct in the Instructions section of the description...
"You will write a function describe taking a function's source code..."

Really enjoyed this kata though, thanks!

I've just returned to this and knocked up the code so that it returns 0 each time. An example here of the test failing is...

Testing for 'ovuwwaxbugeaweoluuea'

0 should equal 2

My expectation would be that I should have returned 4, corresponding to the four vowels at the end (uuea) however, the test case expects 2, and looking at similar test cases, it appears to be discounting any groups that appear at the end of the string.