Day 18: Ram Run
Megathread guidelines
- Keep top level comments as only solutions, if you want to say something other than a solution put it in a new post. (replies to comments can be whatever)
- You can send code in code blocks by using three backticks, the code, and then three backticks or use something such as https://topaz.github.io/paste/ if you prefer sending it through a URL
FAQ
- What is this?: Here is a post with a large amount of details: https://programming.dev/post/6637268
- Where do I participate?: https://adventofcode.com/
- Is there a leaderboard for the community?: We have a programming.dev leaderboard with the info on how to join in this post: https://programming.dev/post/6631465
On the topic about flood fill and other path finding algorithms. I do think your method is quite fast. However, I saw on reddit someone saw Part 2 as more of a tree phenomena called “Crown shyness” where two trees limit their growth to prevent touching each other.
so the idea behind the “Crown shyness” approach is that when you add a block, you find which corner(top right or bottom left) it is connect to(or in union) until one block connects both corners. so instead of path finding, you are connecting walls to one side. This is also called the “Union-Find algorithm” and the optimization is that when a block drops, you calculate what it is connect with. you can find some visualization of it as that would make it easier to see. This method is by far way more performant, because you can be sure that with all the blocks placed, then the blocks are all in one union, but as you remove blocks you eventually have two unions appear! That block would be the solution.
Your flood fill is mimicking this closely but instead of union of walls, it is finding if there is a union between the start and end nodes, or top left node with bottom right node. When that wall that blocks the path is placed, it will create two unions for the start and end node.
I think I saw the same! At first I thought it requires pathfinding to see what nodes are connected to the wall, but then someone pointed at disjoint sets and just a glance at Wikipedia made it click right away. What an ingeniously simple but useful data structure! Maybe I’ll reimplement my solution with that - mostly as an exercise for disjoint sets and finding a convenient representation for that in C.
That would be cool af to see in C, let me know if you do. In python, we can built the two sets, and have the convenient function call of
set( [iterate-able object/list/set] ).intersection( [iterate-able object/list/set] )to see if the two sets touches/intersects as the block that connects the two sets would be in both sets/lists.The way I would build the two sets would be to start at the final state with all blocks placed and just union-find all the blocks. When we find that a block appears in both sets, then we stop the union and proceed with the other unions until we find all the blocks that would appear in both sets. then we iteratively find the first block that would appear in both sets. In python the intersection call returns a set, so you can stack the intersect call. like so:
set( [top right union set] ).intersection( [bottom left union set] ).intersection( [ one item list with the current block we are checking ] )technically you can just save the intersections of the first two sets to save a little time because they would not change.I didn’t think of this until recently, but I also think it is such a simple and elegant solution. Live and learn! 😄
hope you are having a good holiday season!