Day 14: Restroom Redoubt
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
21 Comments
sjmulder@lemmy.sdf.org · 4 pts · 1y
C
Solved part 1 without a grid, looked at part 2, almost spit out my coffee. Didn't see that coming!
I used my visualisation mini-library to generate video with ffmpeg, stepped through it a bit, then thought better of it - this is a programming puzzle after all!
So I wrote a heuristic to find frames low on entropy (specifically: having many robots in the same line of column), where each record-breaking frame number was printed. That pointed right at the correct frame!
It was pretty slow though (.2 secs or such) because it required marking spots on a grid.
I noticed the Christmas tree was neatly tucked into a corner, concluded that wasn't an accident, and rewrote the heuristic to check for a high concentration in a single quadrant.Reverted this because the tree-in-quadrant assumption proved incorrect for other inputs. Would've been cool though!::: spoiler Code
:::
https://github.com/sjmulder/aoc/blob/master/2024/c/day14.c
gedhrel@lemmy.world · 4 pts · 1y
Haskell, alternative approach
The x and y coordinates of robots are independent. 101 and 103 are prime. So, the pattern of x coordinates will repeat every 101 ticks, and the pattern of y coordinates every 103 ticks.
For the first 101 ticks, take the histogram of x-coordinates and test it to see if it's roughly randomly scattered by performing a chi-squared test using a uniform distrobution as the basis. [That code's not given below, but it's a trivial transliteration of the formula on wikipedia, for instance.] In my case I found a massive peak at t=99.
Same for the first 103 ticks and y coordinates. Mine showed up at t=58.
You're then just looking for solutions of t = 101m + 99, t = 103n + 58 [in this case]. I've a library function, maybeCombineDiophantine, which computes the intersection of these things if any exist; again, this is basic wikipedia stuff.
hades@lemm.ee · 2 pts · 1y
gedhrel@lemmy.world · 2 pts · 1y
I should add - it's perfectly possible to draw pictures which won't be spotted by this test, but in this case as it happens the distributions are exceedingly nonuniform at the critical point.
Gobbel2000@programming.dev · 2 pts · 1y
Very cool, taking a statistical approach to discern random noise from picture.
gedhrel@lemmy.world · 2 pts · 1y
Thanks. It was the third thing I tried - began by looking for mostly-symmetrical, then asked myself "what does a christmas tree look like?" and wiring together some rudimentary heuristics. When those both failed (and I'd stopped for a coffee) the alternative struck me. It seems like a new avenue into the same diophantine fonisher that's pretty popular in these puzzles - quite an interesting one.
This day's puzzle is clearly begging for some inventive viaualisations.
JRaccoon@discuss.tchncs.de · 3 pts · 1y
TypeScript
Part 2 was a major curveball for sure. I was expecting something like the grid size and number of seconds multiplying by a large amount to make iterative solutions unfeasible.
First I was baffled how we're supposed to know what shape we're looking for exactly. I just started printing out cases where many robots were next to each other and checked them by hand and eventually found it. For my input the correct picture looked like this: ::: spoiler The Christmas tree
:::
Later it turned out that a much simpler way is to just check for the first time none of the robots are overlapping each other. I cannot say for sure if this works for every input, but I suspect the inputs are generated in such a way that this approach always works. ::: spoiler The code
:::
lwhjp@lemmy.sdf.org · 2 pts · 1y
Checking for no overlaps is an interesting one. Intuitively I'd expect that to happen more often due to the low density, but as you say perhaps it's deliberate.
gentooer@programming.dev · 3 pts · 1y
Haskell. For part 2 I just wrote 10000 text files and went through them by hand. I quickly noticed that every 103 seconds, an image started to form, so it didn't take that long to find the tree.
::: spoiler Code
:::
iAvicenna@lemmy.world · 2 pts · 1y
Python
I was very confused when I saw the second part. I was like "how the fuck am I supposed now how that shape will exactly look like?" I looked a couple of initial shapes all of which looked sufficiently random. So I constructed x and y marginal distributions of the robots to impose some non-symmetry conditions.
My initial attempt was to just require maximum of x marginal should be at the centre but the sneaky bastards apparently framed the tree and tree was shorter than I expected (realised this only later) so that did not return any hits. I played around a bit and settled for: most of the maximums of x marginal should be near the centre and y marginal should be asymmetric. I still had to play around with the thresholds for these a bit because initially there was a couple of shapes (some repeating every 100 cycles or so) that satisfied my requirements (I had a part which actually outputted found shapes to a text file but then removed that in the final code). So it wasn't %100 free of manual labour but I can say mostly...
mykl@lemmy.world · 2 pts · 1y
Dart
Took far too long to work out a really stupidly simple method of finding the tree -- I ended up just checking the first height*width time slots to find when the most bots appear in any given row/column. The framing around the Christmas tree accidentally made this foolproof :-). Add a bit of Chinese Remainder Theorem and we're golden. (edit: forgot to mention that it's Dart code)
VegOwOtenks@lemmy.world · 2 pts · 1y
Haskell
I solved part two interactively, I'm not very happy about it
::: spoiler Reveal Code
:::
Gobbel2000@programming.dev · 2 pts · 1y
Rust
Part 2 was very surprising in that it had a very vague requirement: "Find christmas tree!". But my idea of finding the first round where no robots overlap turned out to just work when printing the map, so that was nice. I'm glad I did not instead start looking for symmetric patterns, because the christmas tree map is not symmetric at all.
::: spoiler Solution
:::
Also on github
janAkali@lemmy.one · 2 pts · 1y
Nim
Part 1: there's no need to simulate each step, final position for each robot is
(position + velocity * iterations) modulo gridPart 2: I solved it interactively: Maybe I just got lucky, but my input has certain pattern: after 99th iteration every 101st iteration looking very different from other. I printed first couple hundred iterations, noticed a pattern and started looking only at "interesting" grids. It took 7371 iterations (I only had to check 72 manually) to reach an easter egg.
Codeberg Repo
RagingHungryPanda@lemm.ee · 2 pts · 1y
This one was wild. At first I started visualling it but wasn't seeing anything. I went up to almost 80 iterations before giving up. I then went with the "no overlapping points thing" but didn't think that was working for me either.
It was iteration 7,753. f's sake man.
I used the a modulo operation and an if check to skip ahead to the final state. It was also tricky b/c the grid is larger than I could get my console to work with.
F#
(just the important bits)
CameronDev@programming.dev · 2 pts · 1y
I got so lucky that "no overlapping" worked for mine. It was a very undefined problem.
RagingHungryPanda@lemm.ee · 2 pts · 1y
Yeah I don't know how long I would have tried to solve that on my own. I was starting to wonder if I did something wrong because I read seeing patterns every 80 iterations or so
CameronDev@programming.dev · 1 pts · 1y
Someone did use that periodic pattern to cut down on the search space.
RagingHungryPanda@lemm.ee · 1 pts · 1y
I saw that. I think it sort of made sense haha. There's a reason I'm not in statistics or analytics lol
lwhjp@lemmy.sdf.org · 2 pts · 1y
Haskell
Part 2 could be improved significantly now that I know what to look for, but this is the (very inefficient) heuristic I eventually found the answer with.
::: spoiler Solution
:::
LeixB@lemmy.world · 1 pts · 1y
Haskell
Spent a lot of time trying to find symmetric quadrants. In the end made an interactive visualization and found that a weird pattern appeared on iterations (27 + 101k) and (75 + 103k'). Put those congruences in an online Chinese remainder theorem calculator and go to the answer:
x β‘ 8006 (mod 101*103)hades@lemm.ee · 1 pts · 1y
Quant@programming.dev · 1 pts · 1y
Uiua
Ok, so part one wasn't too hard, and since uiua also takes negative values for accessing arrays, I didn't even have to care about converting my modulus results (though I did later for part two).
I'm a bit conflicted about the way I detected the quadrants the robots are in, or rather the way the creation of the mask-array happens. I basically made a 11x7 field of 0's, then picked out each quadrant and added 1-4 respectively. Uiua's group (
β) function then takes care of putting all the robots in separate arrays for each quadrant. Simple.For part two, I didn't even think long before I came here to see other's approaches. The idea to look for the first occurrence where no robots' positions overlapped was my starting point for what follows.
::: spoiler Example input stuff Run with example input here
:::
Now on to the more layered approach of how I got my solution.
In my case, there's two occasions of non-overlapping positions before the christmas tree appears.
I had some fun trying to get those frames and kept messing up with going back and forth between 7x11 vs 103x101 fields, often forgetting to adjust the modulus and other parts, so that was great.
In the end, I uploaded my input to the online uiua pad to make visualizing possible frames easier since uiua is able to output media if the arrays match a defined format.
::: spoiler Try it out yourself with your input
0in the first line with your solution for part twoI used this code to find the occurrence of non-overlapping positions (running this locally):
Whenever a new case was found, I put the result into the code in the online pad to check the generated image, and finally got this at the third try:
