I found your objection here confusing until I thought about it.

Fundamentally, I agree. However, I think the underlying problem isn't the logic of planets leaving the system. That's a symptom. The problem is that the orbits change. As you note, if a planet leaves the system on the left, all other planets shift to fill lower orbits. However, if a planet is destroyed the same thing happens. The logic is consistent and solvable, but it's weird. There's a sort of extra movement built into it.

My biggest complaint, I think, is that the series didn't build upon itself. It would have been great if each new entry in the series added instead of being essentially the same with a different skin.

To aleviate any potential confusion for future warriors attempting the kata:

Path components of more than one word are given hyphenated. When creating the text content of a breadcrumb, you should:

• Initialize the path component without hyphens for path components with length greater than 30: (e.g. EEUU not E-E-U-U)
• Replace the hyphens with spaces for path components with 30 characters or less.

easy

excellent

There are always constraints. On codewars we are constrained by the resources given to us and the amount of time alloted to pass. There are n that are both practically and theoretically impossible to compute within those time and resource constraints. Can anyone's solution here actually compute up to 2520 in those 12 seconds on codewars' system?

First of all, thanks!
About the round subject, it's true that the way that it was written could lead to a misunderstanding of the task so I have changed it.

Also, I will keep the sugestion in mind for what will most likely become the second part of this kata, harder and definitely more interesting!

Nice kata. Just a note that I found the bit about 'rounds' confusing. The way I read it, a round was 'the octopus types 8 letters', but the kata requires a round to be '8 letters of input whether they get typed or not'. I think the former is the more interesting challenge (maybe a sequel kata?).

Strictly speaking, the time complexity of 'stop at 5' would be:

O(min(N, f(k))) where f(k) is the number of elements needed to inspect for the given inputs (implying 5 <= f(k) <= N). This means the 'stop at 5' solution is better in all cases except the worst case.

The overhead of checking the count is practically nothing and I struggle to think of a scenario (extremely small dictionaries?) where it isn't worth it to keep the count and stop.

Idk how rated it as 6 kata... I struggeled for 2+ hours and couldnt solve it... I feel like I was close to completion but for now.. i just skip this one

The specification should say that it is looking for the minimum-sized matrix that meets the criteria. Although it is possible to guess what is expected based on the specification examples, example tests, and trial and error, the specification should still give all the information needed to meet the criteria. (I'm not raising this as an issue since the kata is already approved and solved by hundreds.)

As the specification is written the following (and any similar) matrix should be an acceptable output:

[
  ['B','i','l','l'],
  ['.','.','.','.'],
  ['.','.','.','.'],
  ['.','.','.','.'],
  ['.','.','.','.']
]

Docstring is missing examples. My smol brain cannot understand. Plz update ASAP.

Assets should be a superset of both equities and currencies. I think the problems are the places in the descriptions where assets and equities are used interchangably.

Edit: Or, since he seems to want separate imports for these different asset classes, he should specify the asset types in the argument, like you suggest.

Second Edit: On third thought, I think get_shift arguments are named just fine, but asset_import should either handle all types of assets or be renamed to equity_import but also include in its name evidence that we're importing historical data and not data regarding the users holdings.

This does not resolve the issue. The issue is this:

1. That calculate_check_digit is expected to return an int.
2. That it is not specified that calculate_check_digit is expected to return an int.
3. That, if a str is returned, the kata considers this a wrong answer, but does not inform the user of the correct value so they may discern that they failed because an int was expected.

Put simply, there is no logical way for the user to know that an int is expected rather than a str. It cannot logically follow that an int is expected because calculations were performed on an int, because there are valid reasons to for both cases and it is simply a choice you made.