13
Kristoffel Pirard
Last seen 4 years ago
Member for 9 years, 9 months, 23 days
Difficulty Normal
Darn... it took me a while to wrap my head around the `freqs` spell, but now I can happily start 2015. It is neat how it reverses the way I think about it.
More
Hah! Finally someone like me :). I daresay I feel relieved I'm the only one not thinking `set` when thinking of Conway's game of Life.
More
Why bother with all these different dimension combinations? Just keep the empty one and the general one, and you're done.
More
At first glance, this one looks really great! Certainly a zero clutter solution!
At second glance, my unit tests fail on it. That's because the type of the incoming data is changed into a list of tuples. The `==` doesn't care about the type. The unittest `self.assertEqual` does.
So why not be
More
Quite a find, to represent the sparse matrix as a series of living-cell-coordinates. It matches the problem greatly! It reads like a fairy tale. Or a poem if you prefer.
Am I mistaken if I say that the runtime complexity is quite big, however? Take a grid
xxx
x.x
xxx
-> the center
More
Style remark: variable names tend to start with lower case in Python code.
`queue[len(queue) - 1]` can be written as `queue[-1]`
`Answer += 0`... why? Your can lose clutter by reversing the condition:
if queue:
answer += queue[-1]
`print(answer)`: is that a debugging left-over?
More
Great! Dispatching separated from function!
I'm just wondering why you `return` a value from each of your functions...
More
Quite clear solution.
Checking for the second letter is an unneeded twist; you're lucky there is no 'ROTATE' command.
The `else` branch in your loop is unneeded, too, though it makes the program more robust, analogous to the ability to POP from an empty stack.
In order to keep a larger interpret
More
After reformatting (no runtime cost :)
return
sum(
sum( ((0,) + l) [col:col + 3] )
for l in (((0,),) + grid)[row:row + 3])
- grid[row][col]
Great find to just subtract `grid[r][c]` in the end!
What is the use for `((0, ) + l)` as opposed to just `
More
Coming from C, this is a very clear solution.
The vast number of conditions, nested loops and `continue` statements makes it hard to relate to the problem statement. Python offers [generator expressions](https://wiki.python.org/moin/Generators) to simplify this greatly. You should give them a t
More
very clear, expressing the `neighbors` as a plain tuple! Alignment can make these coordinates visible at a glance:
[-1, -1], [-1, 0], [-1, 1],
[ 0, -1], [ 0, 1],
[ 1, -1], [ 1, 0], [ 1, 1]
It takes some time to understand the `tempx, tempy` expression - as dedicated and clear
More
Smart, to work with the `scope` intermediary. Smart trick to filter for `x or y`.
On the other hand, I had a hard time understanding the flow within your `for b, a in around:`. It's probably easier to understand if you introduce a new variable for the new `row, col`, like `row, col = x + a, y + b
More
Nice and dense. You don't _have_ to make it a list, if you use the `sum(1 for w in ....)` idiom. This way you can count iterators without memory limitations.
More
You know that `x.__contains__(y)` can be (and should be) written as `y in x`?
More
I love it when solutions teach me about existing library functions! Sharp and concise, this is!
More
Interesting that you would pick the second char of the command to base your decision upon. What happens when you introduce a "CUT " command...?
You can omit the `len` test:
if l:
del l[0]
More
Indexing the given OPERATOR_NAMES just ties your code tightly to the order the operators are defined in. Tight coupling should be avoided at all cost - at least in a program where maintainability is an issue.
Also: the | operator is a 'bitwise or', not your old 'logical or' (cfr https://wiki.pyt
More
Linear search through the if-statements can easily be replaced by a dict of functions.
And returning True and False just obfuscates the meaning of the code: simply returning a predicate should do.
More