38
juestr
17 44 52 Leader of the month
8720/ 9195
Awesome Team Jürgen Strobel
Last seen 20 hours ago
Member for 5 years, 1 month, 11 days
Difficulty Normal
Best reviews / Newest reviews
First-mpohily
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
list.count()-pavlik 1
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
First-popomin
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
"Pawn Brotherhood"-quarashi
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
Resolved using sorted function-ryychuu01
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
First-Ycq
if ... return True else return False is redundant, you can just return the condition. More
4-liner: no title-przemyslaw.daniel 1
Tricky and very inefficient for large numbers, should be in weird category. More
First-yoichi
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
In 2 string-RavenRu
Using ```min``` instead of ```sorted``` would be much more efficient with almost the same code. More
First-Kofi_Otuo
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
First-Forlena 1
```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
2-liner: h#e#l#p-przemyslaw.daniel 1
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
First-mrflamm87
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
First-juestr
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
First-yuwai
You should lower() earlier or in both top level loops, this applies it only to vertical matches. More
Sum positions-fed.kz
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
Rathe simple solution -Taras_Lutsyshyn
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
Text editor-DmytroKaminskiy
A simple list would suffice for SavedText.storage, and appending to it. Then there's no need for the counter. More
Worth of Words-DmytroKaminskiy
The builtin max() function could replace your sorted with very little modifications and much better efficiency. More
ValuePerWeightSorting-Kouri
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
1 2 3 4
5
6