Day 16: The Floor Will Be Lava
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
10 Comments
cacheson@kbin.social · 3 pts · 2y
Nim
I'm caught up!
This one was pretty straighforward. Iterate through the beam path, recursively creating new beams when you hit splitters. The only gotcha is that you need a way to detect infinite loops that can be created by splitters. I opted to record energized non-special tiles as
-or|, depending on which way the beam was traveling, and then abort any path that retreads those tiles in the same way. I meant to also use+for where the beams cross, but I forgot and it turned out not to be necessary.Part 2 was pretty trivial once the code for part 1 was written.
CommunityLinkFixer@lemmings.world · 1 pts · 2y
Hi there! Looks like you linked to a Lemmy community using a URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !nim@programming.dev
hades@lemm.ee · 3 pts · 2y
cvttsd2si@programming.dev · 2 pts · 2y
Scala3
This could be much more efficient (and quite a bit shorter), but I wanted to try out the scala-graph library (https://www.scala-graph.org)
Gobbel2000@feddit.de · 2 pts · 2y
Rust
I simply check each starting position individually for Part 2, I don't know if there are more clever solutions. Initially that approach ran in 180ms which is a lot more than any of the previous puzzles needed, so I tried if I could optimize it.
Initially I was using two hash sets, one for counting unique energized fields, and one for detecting cycles which also included the direction in the hash. Going from the default rust hasher to FxHash sped it up to 100ms. Seeing that, I thought that this point could be further improved upon, and ended up replacing both hash sets with boolean arrays, since their size is neatly bounded by the input field size. Now it runs in merely 30ms, meaning a 6x speedup just by getting rid of the hashing.
sjmulder@lemmy.sdf.org · 1 pts · 2y
C
Just tracing the ray. When it splits, recurse one way and continue the other. Didn't bother with a direction lookup table this time, just a few ifs. The ray ends when it goes out of bounds or a ray in that direction has been previously traced on a given cell (this is tracked with a separate table).
It would've been straightforward if I hadn't gotten the 'previously visited' check wrong 😞. I was checking against the direction coming in of the tile but marking the direction going out.
Ray function:
reboot6675@sopuli.xyz · 1 pts · 2y
Golang
Avoided recursion by having an array of "pending paths". Whenever I hit a splitter, I follow one of the paths straight away, and push the starting point and direction of the other path to the array.
First time I ran it, hit an infinite loop. Handled it by skipping "|" and "-" if they have been visited already.
Part 2 is the same code as part 1 but I just check all the possible starting points.
::: spoiler Code
:::
LeixB@lemmy.world · 1 pts · 2y
Haskell
A bit of a mess, I probably shouldn't have used RWS ...
mykl@lemmy.world · 1 pts · 2y
Dart
I'm cheating a bit by posting this as it does take 11s for the full part 2 solution, but having tracked down and eliminated the excessively long path for part 1, I can't be bothered to do it again for part 2.I'm an idiot. Avoiding recursively adding the same points to the
seenset dropped total runtime to a hair under 0.5s, so line-seconds are around 35.SteveDinn@lemmy.ca · 1 pts · 2y
C#
Breadth-first search, then take the max of the values of searches starting from all the edge tiles.
https://code.dinn.ca/stevedinn/AdventOfCode/src/branch/main/2023/day16/Program.cs
lwhjp@lemmy.sdf.org · 1 pts · 2y
Haskell
A pretty by-the-book "walk all paths" algorithm. This could be made a lot faster with some caching.
::: spoiler Solution
A whopping 130.050 line-seconds! :::