4
votes
Day 9: Movie Theater
Today's problem description: https://adventofcode.com/2025/day/9
Please post your solutions in your own top-level comment. Here's a template you can copy-paste into your comment to format it nicely, with the code collapsed by default inside an expandable section with syntax highlighting (you can replace python with any of the "short names" listed in this page of supported languages):
<details>
<summary>Part 1</summary>
```python
Your code here.
```
</details>
Not especially happy with my solution, but it does the job. Runs in just under a second on my machine. The idea is, if none of the lines between red tiles are overlapping with the rectangle, then the rectangle is inside the loop. The time complexity of this seems pretty bad, but I unfortunately don't have the time to figure out how to make it more efficient right now.
Solution (Lily)
I thought about the same idea (checking if we're crossing lines), but I feared that it could yield false positives in cases where we have two lines without any gap between them. Something like this:
with the inside on the right side.
As often, the inputs tend to have nice properties not mentioned in the problem statement that allow for some approaches that don't work in the general case.
The general case of this would be pretty tricky, yeah (and probably pretty slow, at least with a naive approach... my solution isn't the fastest as it is). I can confirm my program returns the wrong answer for your test input here. Since these kinds of quirks in the input are generally consistent across all inputs for a given puzzle, though, I don't mind taking advantage of them where possible.
Yeah, I was worried about this and a few other possible pitfalls while working on my solution.
I spent a substantial amount of time writing checks to confirm all of the following:
First day where I don't immediately see how to solve the problem efficiently. In the end, my idea of compressing the coordinates for visualization purposes turned out to actually be a key idea to quickly solve part 2.
Unfortunately, I had a stupid bug in my computation for the size of rectangles (doing abs(a-b+1) instead of abs(a-b)+1), and that didn't matter for either examples nor for part 1. If it wasn't for @lily's posted solution, which allowed me to figure out that none of the rectangles matched the size of the expected answer, I don't know how I would have found this bug.
After fixing the bug, I got the right answer in ~9ms.
Another idea for part 2 is that all the outside points are visible from the border of the map. So it's sufficient to keep track of the min and max x for all y and y for all x. Then, it's possible to check whether the edges of the rectangle are contained within those min/max values. Without coordinate compression, this approach takes ~1s. With coordinate compression, it's down to ~5ms.
Solution (Rust)
I had this idea too, mostly because I wanted to visualize the output, and it's too big to print uncompressed. It didn't lead me to any insights though. Can you explain what you thought?
The idea was that building an in-memory map of all the points that are inside vs outside would require way too much memory using the provided coordinates. However, the compressed model fits in a 500x500 map, which is trivial to fit in memory. If the compression is correctly done, then a rectangle that is fully inside in the compressed version is also going to be fully inside in the uncompressed version. Thus, it's possible to use the naïve approach of just testing all possible rectangles and checking if they are contained in the perimeter. You just need to be careful to use the real coordinates to compute the area of the rectangle instead of the compressed coordinates.
I see. I wound up representing everything as a hash set of known coordinates, instead of simulating the whole grid. So, at least for my solution, compressing the coordinates wouldn't have made any practical difference.
I love the idea of compressing the coordinate space to be able to represent it as a full grid instead of sparse set of points. That's so clever!
Wow, I don't think I've seen such a jump in difficulty between Part 01 and Part 02. The first part was trivially easy, and the second part I have basically given up on a pleasing solution... or even a general one.
Given the large search space, I knew the in-memory representation had to be sparse, and I'd likely need to take some shortcuts based on my particular input. I ran a validator and confirmed that no 2 consecutive red tiles are adjacent and no 3 consecutive red tiles are collinear. Based on that I figured it's likely a rectangle is "inside" if it doesn't intersect any edges.
My original approach was to use set intersection to test every edge simultaneously (or at least let the CPython set intersection code do it for me which I hoped would be fast). Alas no. This is catastrophically slow given the size of the grid (and is still running). I afterwards switched to a sparser line/box intersection check for each edge that completes in ~10 seconds.
There are many adversarial inputs for which my solution doesn't work. Even for the sample input it gets the right answer but using the wrong corner tiles. The selected rectangle is technically "outside." It feels hacky and unearned; plus I just kind of don't like it code-wise.
:/
Part 1
Part 2
Part 1: less than 5 minutes. Part 2: several hours of frustrating coding, just to finally import a library that does all the hard parts. I saw someone mention Shapely in a Reddit post, and figured that I'd learn a lot more by playing around with a new library than just brute forcing a solution poorly.
Tomorrow's goal is to discover the best python library for the job without first reading AoC threads on Tildes or Reddit. If Part 2 was any indication, I think it's well past the point where I can solve the upcoming challenges with barebones Python.
Part 1 and 2 [Python]
I've never done graphical stuff before, so this is pretty basic, but I've plotted the whole floor and all of the valid rectangles. It's pretty crowded, since there's so many rectangles, so you can't tell which is the largest, but the shape of the floor is kinda spoilery information (if you've made it this far into the comments and are still trying to avoid spoilers).
Sample data visualization
"Real" data visualization
Thanks for the hint about Shapely. I wasn't able to solve yesterday, got encouraged by today's part 1 being trivial, then failed to solve part 2 after lots of effort. I was about ready to admit that maybe I've reached the difficulty spike where I can't solve these things in a reasonable time, but after finding that library I was at least able to get a working solution. I'm writing this just as next day's puzzle goes live, so I'll at least give that one a look without being completely deflated!
Catching up on the last couple of days. This one went alright, though I was just lazy and figured at ~500 points I could probably get away with an n^3 solution. I believe I could get it to n^2logn without too much trouble if I had some more powerful data structures, but I already felt like a cheated on day 8 already by using a pre-made union-find.
Prolog Solution