13
Kristoffel Pirard
Last seen 4 years ago
Member for 9 years, 9 months, 10 days
Difficulty Normal
Quite clear and very pragmatic, to say the least. Using a string representation for the combos makes your code very (human) readable.
I wonder, is it possible to reduce line 12-13 to something more readable
for a, b, c in combos:
if x[a] == x[b] == x[c] and x[a] in "XO":
This becomes
More
I love it when solutions teach me about existing library functions! Sharp and concise, this is!
More
Unknown operations return zero in this implementation - It's more correct to raise an error (KeyError would be ok).
More
nice one! The `zip` doesn't add much, though - you can just as well hand-zip it, and keep the relation between divider and key: `x, name in [(3, "Fizz"), (5, "Buzz")]
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
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
Great! Dispatching separated from function!
I'm just wondering why you `return` a value from each of your functions...
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
First-makoto_yamagata
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
Why bother with all these different dimension combinations? Just keep the empty one and the general one, and you're done.
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
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
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
Functionally correct, but it's an anti-pattern to
if predicate:
return True
else:
return False
Returning the predicate directly reduces the amount of nested blocks, and thus yields shorter _and_ clearer code:
return any(l.isupper() for ...) and (...) and (...)
More
Great separation of concerns by using a 'rules-database'.
One thing only: the return-predicate antipattern: instead of writing
if predicate:
return True
else:
return False
write
return predicate
More
This is a solution I can follow. In fact I used the same path-generating algorithm, but made it somewhat readable using helper functions.
More
What I learn from your solution: Know your algorithms... It took me about 200 lines and a couple of hours of research to achieve something working. (it is unit tested, though :)
On the other hand, reverse-engineering this solution is only possible because now I can map it onto e.g. the A* shortes
More
First-homo_ludenus
very clear solution. Personally I'm a bit appalled by these long lines (you're free to rename `game_result` to something shorter) and all these brackets, but that's personal.
The `elif` on line 6/10 are not needed.
More
