38
Awesome Team
Jürgen Strobel
Last seen 20 hours ago
Member for 5 years, 1 month, 11 days
Difficulty Normal
It's a tad easier to get the 3 digits by % and // operators than string conversion and back.
The loop/continue/break flow control is hard to follow.
More
Does the job, however needs many more count()s than necessary. It's also superfluous to return a list (extra alloc). I doubt filter() is good style here.
More
Quite nice. A possible improvement would be to drop the string presentation and just use an int for the number of white marbles throughout, since order does not matter.
More
The yoko lookup is a nice idea, but index() calls and handling of edge cases makes it rather inefficient and unwieldy compared to ord/chr conversions.
More
Using sorting is for sure not intended here, this would be bad for a library function. min/max can be done in O(n), sort is O(n log n).
More
if ... return True else return False is redundant, you can just return the condition.
More
Tricky and very inefficient for large numbers, should be in weird category.
More
Nice, I also tried an approach with permutations().
However checking adjacent pieces corresponding heights at the top of can_restore was not intended, and breaks some of the random tests. You likely got lucky, an example which is supposed to work but doesn't with your code is:
[[0, 5, 1, 1, 0
More
Using ```min``` instead of ```sorted``` would be much more efficient with almost the same code.
More
It's generally not needed or even desirable to check for preconditions, they are given so that your code doesn't need to handle them. Also, using min() instead of sort() leads to a much more efficient solution.
More
```if COND return True else return False``` can be trivially shortenend
to ```return COND```, or ```return bool(COND)``` if COND is not of type
bool already.
Also you could join the 3 regular expressions with | which makes
```re.search``` more efficient and naturally reduces the calls to
```l
More
Hmmm the regex looks a bit off, first the ? following * is redundant. More importantly matching any non space character for padding is probably not what was wanted, this would mark as stressfull words like HEmLineProof or constructs like A_SpeciAl_Problem.
More
The first if statement is redundant with the repeated tests in return, and b is never used?!
Also calling ```__contains__``` directly is bad style, just use ```x in checks``` in general, or ```any(checks)``` in this case to find a True value. Or move the return into the outer loop for a shortcut re
More
Also see this [improved version](https://py.checkio.org/mission/sort-array-by-element-frequency/publications/juestr/python-3/revisited-enumerate-is-more-efficient-than-listindex/).
More
You should lower() earlier or in both top level loops, this applies it only to vertical matches.
More
IMHO the recalculation of first for every term in the last sum is neither clear nor efficient, nor actually saves characters, and so isn't worthwhile just to save a single line with a simple assignment.
pos_y = find_position('Y')
More
Good catch on using Counter.
itertools.combinations would be more efficient than permutations, since the line defined by (dog1, dog2) is the same as the line defined by (dog2, dog1).
Ignoring ZeroDivisionError only works because there are no tests where a vertical line is the result.
More
A simple list would suffice for SavedText.storage, and appending to it. Then there's no need for the counter.
More
The builtin max() function could replace your sorted with very little modifications and much better efficiency.
More
I am quite disappointed this simple greedy algorithm passes all tests (it does, I checked).
There are easy to find problem instances where this yields wrong results, like:
treasures({'golden coin': {'price': 100, 'weight': 50, 'amount': 200},
'silver coin': {'price': 35, 'weig
More