Day 18: Lavaduct Lagoon
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
14 Comments
hades@lemm.ee · 3 pts · 2y
sjmulder@lemmy.sdf.org · 2 pts · 2y
C
Fun and interesting puzzle! In part 1 I fumbled a bit trying to implement even/odd outside/inside tracking before realizing that wouldn't work for this shape and just did the flood fill.
For part 2 I correctly guessed that like the intersecting cuboids (2021 day 22) it would be about finding a better representation for the grid or avoiding representing it entirely. Long story shorter:
Despite being quite happy with this solution, I couldn't help but notice the brevity and simplicity of the other solutions here. Gonna have a look what's happening there and see if I can try that approach too.
(Got bitten by a nasty overflow btw, the list of unique X coordinates was overwriting the list of unique Y coordinates. Oh well, such is the life of a C programmer.)
https://github.com/sjmulder/aoc/blob/master/2023/c/day18.c
lwhjp@lemmy.sdf.org · 1 pts · 2y
Oh, just like day 11! I hadn't thought of that. I was initially about to try something similar by separating into rectangular regions, as in ear-clipping triangulation. But that would require a lot of iterating, and something about "polygon" and "walking the edges" went ping in my memory...
zarlin@lemmy.world · 2 pts · 2y
Nim
Decided to go for a polygon approach for part 1 using the Shoelace formula to calculate the area. This meant part 2 only resulted in larger values, no additional computation.
Code runs in <1ms for part 1 and 2 combined
Source
cacheson@kbin.social · 3 pts · 2y
This would have been really useful to know about. I've committed to a certain level of wheel-reinvention for this event unless I get really stuck, but I'm sure it'll come up again in the future.
zarlin@lemmy.world · 3 pts · 2y
This was actually something I learned for my job, it was nice to be able to apply it here.
I like your commitment to wheel-reinvention, it can be a lot more fun than going for an existing or 'intended' approach.
cacheson@kbin.social · 2 pts · 2y
Yep, I figure it's good exercise to make me think through the problems thoroughly.
cacheson@kbin.social · 2 pts · 2y
Nim
I am not making good time on these anymore.
For part 1, I walked through the dig plan instructions, keeping track of the highest and lowest x and y values reached, and used those to create a character grid, with an extra 1 tile border around it. Walked the instructions again to plot out the trench with
#, flood-filled the exterior withO, and then counted the non-Otiles. Sort of similar to the pipe maze problem.This approach wouldn't have been viable for part 2, due to the scale of the numbers involved. Instead I counted the number of left and right turns in the trench to determine whether it was being dug in a clockwise or counterclockwise direction, and assumed that there were no intersections. I then made a polygon that followed the outer edge of the trench. Wherever there was a run of 3 inward turns in a row, that meant there was a rectangular protrusion that could be chopped off of the main polygon. Repeatedly chopping these off eventually turns the polygon into a rectangle, so it's just a matter of adding up the area of each. This worked great for the example input.
Unfortunately when I ran it on the actual input, I ran out of sets of inward turns early, leaving an "inside out" polygon. I thought this meant that the input must have intersections in it that I would have to untwist somehow. To keep this short, after a long debugging process I figured out that I was introducing intersections during the chopping process. The chopped regions can have additional trench inside of them, which results in those parts ending up outside of the reduced polygon. I solved this by chopping off the narrowest protrusions first.
zarlin@lemmy.world · 2 pts · 2y
Good job on persevering with this one. Your approach for part 2 sounds quite viable, it is very similar to the Ear clipping method for triangulating a polygon.
cacheson@kbin.social · 1 pts · 2y
Yeah, I read up on ear clipping for a small game dev project a while back, though I don't remember if I actually ended up using it. So my solution is inspired by what I remember of that.
cacheson@kbin.social · 2 pts · 2y
LeixB@lemmy.world · 2 pts · 2y
Haskell
cvttsd2si@programming.dev · 1 pts · 2y
C++
No scala today
cvttsd2si@programming.dev · 1 pts · 2y
looks like some broken XSS protection is killing the includes, can't really fix that
lwhjp@lemmy.sdf.org · 1 pts · 2y
Haskell
Wasn't able to start on time today, but this was a fun one! Got to apply the two theorems I learned from somebody else's solution to Day 10.
::: spoiler Solution
:::