🏃 - 2024 DAY 18 SOLUTIONS - 🏃
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
Haskell
::: spoiler solution
:::
Haskell
Not really happy with performance, binary search would speed this up a bunch, takes about 1.3 seconds.
Update: Binary search got it to 960 ms.
::: spoiler Code
:::
::: spoiler Faster (binary search)
:::
Haskell
Wasn't there a pathfinding problem just recently?
Edit: Optimization to avoid recalculating paths all the time
::: spoiler Haskell with lambdas
:::
Dart
I knew keeping my search code from day 16 would come in handy, I just didn't expect it to be so soon.
For Part 2 it finds that same path (laziness on my part), then does a simple binary chop to home in on the last valid path. (was
then searches for the first block that will erm block that path, and re-runs the search after that block has dropped, repeating until blocked. Simple but okay.)90 lines, half of which is my copied search method.
Runs in a couple of seconds which isn't great, but isn't bad.Binary chop dropped it to 200ms.::: spoiler That search method
:::
Rust
Naive approach running BFS after every dropped byte after 1024. Still runs in 50ms. This could be much optimized by using binary search to find the first blocked round and using A* instead of BFS, but I didn't feel like doing more today.
::: spoiler Solution
:::
Also on github
C#
Part 1 was straight forward Dykstra with a cost of 1 for each move. Part 2 was a binary search from the number of corrupted bytes given to us for Part 1 (where we know a path can be found) to the total number of corrupted bytes.
JavaScript
This one was fun, and pretty easy.
GitHub
Javascript
Reused my logic from Day 16. For part two I manually changed the bytes (
ion line 271) to narrow in on a solution faster, but this solution should solve it eventually.https://blocks.programming.dev/Zikeji/c8fdef54f78c4fb6a79cf1dc5551ff4d
Haskell
I did an easy optimization for part 2, but it's not too slow without.
::: spoiler Solution
:::
Uiua
I didn't think I could do this in Uiua this morning, but I gave it some thought while walking the dog and managed to wrangle the data into shape tonight. I factored out the binary chop as that seems like another useful tool to have up my sleeve.
EDIT: goddammit, Kai literally snuck a new RC release out just after I posted this, with a breaking change to how
pathworks. Updated version below.Try it here!
::: spoiler spoiler
:::
C
Flood fill for part 1. Little tired so for part 2 I just retry the flood fill every step. Slow by C standards (2s) but I'll let it brew and come back to it later.
::: spoiler Code
:::
https://github.com/sjmulder/aoc/blob/master/2024/c/day18.c
Part 2 can be faster if you iteratively remove blocks until there is a path. This is because it is faster to fail to find a path and the flood fill algorithm does not need to fill as many spots because the map would be filled up with more blocks! this drops the part 2 solve to a few milliseconds. others have taken a binary search option which is faster.
Thanks, that's exactly the sort of insight that I was too tired to have at that point 😅
The other thing I had to change was to make it recursive rather than iterating over the full grid - the latter is fast for large update, but very wasteful for local updates, like removing the points. Virtually instant now!
::: spoiler Code
:::
Wooo! instant is so good, I knew you could do it! When I see my python script getting close to 20 ms, I usually expect my fellow optimized language peers to be doing it faster. Pretty surprised to see so many varying solutions that ended up being a little slower just because people didnt realize the potential of speed from failing to find a path.
The first part has a guaranteed path! if you think about a binary search, when there is a path then the block is higher up the list, so we ignore the lower blocks in the list. move to the next "midpoint" to test and just fill and remove blocks as we go to each mid point. So I took the first part as the lower point and moved to a mid point above that.
at least that is how I saw it, when I first looked, but binary search is a little harder to think of than just a simple for loop from the end of the list back. Yet I still got it done! Even included a dead end filler that takes 7 ms to show the final path for Part 2, it was not needed but was a neat inclusion!
Awesome! I understood the idea behind the binary search but thought it wasn't a good fit for the flood fill. As opposed to something like A* it will give you reachability and cost for every cell (at a cost), but that's no use when you do repeated searches that are only meant to find a single path. So I was very happy with your suggestion, it fits better with the strengths.
"Virtually instant" btw is measured 0.00 by
time. I like it when things are fast but I also prefer simper approaches (that is: loops and arrays) over the really optimized fast stuff. People do really amazing things but the really clever algorithms lean on optimized generic data structures that C lacks. It's fun though to see how far you can drive loops and arrays! Perhaps next year I'll pick a compiled language with a rich data structure library and really focus on effectively applying good algorithms and appropriate data structures.Btw how do you measure performance? I see a lot of people including timing things in their programs but I can't be bothered. Some people also exclude parsing - which wouldn't work for me because I try to process the input immediately, if possible.
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!
ah, I exclude loading and reading the file. but since you are pasting it from pasting into the terminal, that is alright.
My main gripe is that I am looking at the performance of the algorithm/functions over the performance of the disk access and read, the startup/end overhead. Python is notorious in having overhead during startup for loading the code and before execution occurs. Why should I measure the performance of the language too harshly? I rather look at how my code performs. In windows, the python overhead adds 30-40 ms, while on Linux, it performs faster with only an overhead of consistent 20 ms. Though, that is just without importing heavy or many libraries. If startup is a concern, then a precompiled non-interpreted language is a better option.(along with the other benefits) This is my reasoning for only measuring my algorithm. I do include parsing the input as that is part of the challenge, but I do see there are reasons not to do that. when you are looking for code that is performant, you want to scientifically remove too many variables. If you are to reuse some code, lets say the input to that function is already parsed and then you just want performance. However, I do measure my parsing because for the AoC, I want to think about what would be faster to parsing and what is a bad parsing.
For AoC, I find a language overhead is not part of the challenge. we should rather learn new languages when we want or use what is comfortable. however, languages like Uiua with a lot of specialty functions is just not worth measuring performance as the main code is just a simple "function call"
I am sure there is a python package/module that includes a fast path finder, too. I just want to challenge myself mostly to learn instead. however, I am finding I would need to start learning rust instead, because my python skills are starting to plateau.
Python
Nobody posted a solution in python for today???
Here is my solver with a little extra to print the Part 2 path. you can totally remove/comment out the printing out of the part 2 path, but it is neat to look at!
Execution time: ~25 milliseconds + an unnecessary ~7 ms to print part 2 path
[ Paste ]
This is the one where you don't have it print out the Part 2 path and smaller: [ Paste ]
here is also a faster version that uses binary search instead. but its only a few milliseconds faster.
Execution time: ~21 milliseconds + an unnecessary ~7 ms to print part 2 path
[ paste ]
C#
I did flood fill because i normally just do Dijkstra for this kind of stuff. watching the map print as it flooded was cool, had to disable it for part two though as it was too slow. Just let it run while I made a cup of tea instead of doing a binary search.
::: spoiler spoiler namespace AoC2024.Day_18;
public class Day18 {
} :::