| 1 |
✅ |
✅ |
Lists and counters for the win! |
| 2 |
✅ |
✅ |
Lists and np.diff operations |
| 3 |
✅ |
✅ |
re.finditer() and re.findall() worked like magic. Could the part2 code be made shorter? Perhaps a task for the future. |
| 4 |
✅ |
✅ |
Search for substring (XMAS) in a grid in all directions. Boundary check for indices. |
| 5 |
✅ |
✅ |
Custom iterative sorting mechanism was needed. Topological sorting failed due to cycles and exhaustive permutation for part 2 failed due to scalability issues. What a way to learn how sorting operations work 😅! |
| 6 |
✅ |
✅ |
Solving bouncing-board-snake-style game on the grid. Part 2 took 50 seconds to brute-force through all alternatives (perhaps there are ways to avoid duplicate searches?). Key lessons: using pretty_print_grids() (in part2.py) aided debugging, and storing the grid as a list of character lists proved more efficient. |
| 7 |
✅ |
✅ |
itertools.product() did the magic of generating all outcomes from the toss of the operator "coin" being two numbers. Took 14.5 seconds for part2, which could be improved! |
| 8 |
✅ |
✅ |
Goal was to find linear alignments of points in a grid. Logic--first collect the coordinates of each unique character. Then use itertools.combinations and coordinate geometry to generate line segment points and extends them in both directions until the grid boundary is reached. Fun puzzle! |
| 9 |
✅ |
✅ |
Goal was to remove white spaces by pushing file IDs from the end to the front. Somewhat long logic using careful edits to list start and end indices. |
| 10 |
✅ |
✅ |
Goal was to count the number of paths in a topologically sorted network with a set of start and end points. I struggled with choosing the right graph algorithm till realizing the network has a topological order. |
| 11 |
✅ |
✅ |
Goal: Apply a defined rule to manipulate numbered stones for a set number of "blinks" (iterations). For 25 blinks, simple recursion worked well; for 75 blinks, using lru_cache was more efficient. The key insight is that we only need the final count of stones, not their specific values. |
| 12 |
✅ |
✅ |
Part 1 solved using networkx.connected_components(). Part 2 counting of sides was done using the logic by couting all top, bottom, left, and right, edges of a region. |
| 13 |
✅ |
✅ |
Use Cramer's rule to solve two linear equations. A fun one! |
| 14 |
✅ |
✅ |
Part 1 was a recursive update to x and y coordinates. Part 2 felt like brute force to find the tree-looking easter egg. There is fortunately a pattern where x and y coordinates update independently and repeat in vertical and horizontal grouped patterns after every max_col and max_row timesteps. |
| 15 |
✅ |
❌ |
Part 1 was a reasonable move logic. Part 2 is involved. It seems like a BFS at every move to determine which blocks will move and then updating it. I wonder if networkx can solve it? A task for the future self. |
| 16 |
✅ |
✅ |
I used the logic of converting the grid into a networkx DiGraph, and then converting to another line graph (using nx.line_graph()) where weights of edges were carefully designed to find the shortest path minimizing weighted sum of number of turns and number of nodes. For part 2, it was a simple nx.all_shortest_path() function and counting the common nodes across all of them. |
| 17 |
✅ |
❌ |
Part 1 was simple if-else. However, I didn't expect output to be reported as a string and wasted a lot of time debugging. Part 2 seems harder; what would be a smart logic that builds on the repetition pattern? |
| 18 |
✅ |
✅ |
networkx shortest path finder made it simple. In particular, I used nx.shortest_path_length(). Part 2 took approximately 6 seconds. |
| 19 |
✅ |
✅ |
Recursive search for a pattern of string in a given design to find whether the design is possible (part1) and the number of ways to make the design possible (part2). Use lru_cache for memoization. |
| 20 |
❌ |
❌ |
|
| 21 |
❌ |
❌ |
|
| 22 |
✅ |
✅ |
Simple implementation of functions and brute force the logic. Walrus operator (:=) helped and so did np.diff(). |
| 23 |
✅ |
✅ |
Magically easy with networkx clique functions. I used enumerate_all_cliques(G) in forward order for the first, and reversed order for the second. |
| 24 |
✅ |
❌ |
Part 1 was easily rule checking. Part 2 sounds some bit adder concept, a task for my future self to understand and solve. |
| 25 |
✅ |
❌ |
Part 1 was character counting. Part 2 cannot be solved until I have solved all the remaining puzzles. Well! |