AoC 2025 Day 9

Part 1 was pretty easy, but at this point I don't even fully understand the question for Part 2. I'll have to read it again a few times and come back to it.

I understand the question now......... but it hasn't helped.

After nearly 3 hours of runtime I am abandoning my current part 2 solution... I'm pretty much out of ideas for now.

Tim Cooke wrote:Part 1 was pretty easy, but at this point I don't even fully understand the question for Part 2. I'll have to read it again a few times and come back to it.

Agree, part 1 was pretty easy. I got a little tripped up on area calculation because of how a point was considered as having an area of 1 in a thin rectangle. And then I got hung up on the semantics of thick vs thin. On the one hand, I reasoned that a point that has an area of 1 is thick, so why not call it thickArea()? On the other hand, the problem called a single-row rectangle a "thin rectangle" which also made sense. I just settled on thinArea().

The Kotlin solution was short and sweet: https://github.com/jlacar/aoc-in-kotlin-all/blob/main/src/main/kotlin/lacar/junilu/aoc2025/day09/Day09.kt

On skimming through part 2, I had a little déjà vu as I think something very similar to this has come up in a previous year. If I remember correctly, the solution for the past puzzle involved border tracing and corner detection. I think part 2 here will also use these.

Just given part B a thought or two. For each relevant row you can determine a segment with the min and max column of that row, meaning all valid red and green tiles. Likewise for each relevant row, you can determine the accumulated mins and maxes (can be more than one) of all the previous rows. Likewise, for all relevant columns. The idea is that having two corner points of a rectangle it is then very easy to determine whether the other two corners (of which row and column are known) are inside or not. Some programming to do, but quite doable me thinks.

I must admit defeat. Above I described my strategy: for each input-row you can determine the minimum column and the maximum column. These for a segment, and it is given that for each column c in this segment the tile (r, c) is red or green. You can do the same for each input column, with segments of rows. Now, to test whether a tile[row, col) is a valid tile, you just look at the rows above row (or that row itself, to see if any of these rows has a segment that contains this col, and idem for looking below that row. And looking for left and right suitable columns with a segment that contains the row.

Well, I found a rectangle that gives me a "too high", meaning it is wrong but not that much. However, according to what I described, all four corner points are valid.

So I am struck, Is my logic wrong? Did I make a program error? I spent the last two days looking for a bug, but I am unable to find so.

As an aside: to get a Map<row, Segment of columns> I used the collectingAndThen for the very first time. So, if you have a Lisrt of Tiles from the input, you can do:
rowMap = tiles.stream().collect    (   groupingBy(  tile -> tile.row,                     TreeMap::new,                     collectingAndThen(                         summarizingLong(tile -> tile.col),                         lss -> new SegmentB(lss.getMin(), lss.getMax())                     )                   )    ) ; // lss = LongSummaryStatistics
Anyway: is my logic flawed? Can a Tile be invalid even when it has suitable segments above, below, left and right?

Well, after two weeks Xmas and new year, I just restarted day 9. I gave it a lot of thorough re-readings, and I finally understood my misunderstanding. So I tried to come up with a way to get some sort of surrounding of the 'in'-area. And although that worked beautifully for the example, in real the outcome was suspiciously looking like nonsense. So I just wrote a program that visualizes the given points. and I connected points if the y were on the same line or column. Here are the results (for my input, that is): first the complete picture, then a detail of the left side of the diagram:

The question is: in the detail, the small rectangles on the left of the large vertical line, is the inside green or not? I think not, and so I must make an exception for these points, And since it is icy and very slippery outside, I got nothing better to do.

Piet Souris wrote:
The question is: in the detail, the small rectangles on the left of the large vertical line, is the inside green or not? I think not, and so I must make an exception for these points, And since it is icy and very slippery outside, I got nothing better to do.

You might want to double check your plotting program -- Both my puzzle inputs (GitHub and GMail accounts) have the same general Death Star appearance and both have that "equator" channel running through the middle. It's open on the left side and doesn't have any lines crossing the opening as shown in your detailed shot.

My general idea for solving this is to find the largest rectangle that doesn't have any other vertices inside it. The two vertices that form the equatorial indentation will eliminate many rectangles found by the calculation used in the first part of the puzzle.

Junilu Lacar wrote:
You might want to double check your plotting program -- Both my puzzle inputs (GitHub and GMail accounts) have the same general Death Star appearance and both have that "equator" channel running through the middle. It's open on the left side and doesn't have any lines crossing the opening as shown in your detailed shot.

Also, part 2 specifically states that the points in the puzzle input are sequential and each one is connected to the previous and next ones in the list. The last and first points are connected to make the closed polygon. Given that description, the extra lines crossing the indentation opening in your plot detail are most likely caused by a bug in the plotting program.

Thanks, Junilu.

Well, this is the description:

In your list, every red tile is connected to the red tile before and after it by a straight line of green tiles. The list wraps, so the first red tile is also connected to the last red tile. Tiles that are adjacent in your list will always be on either the same row or the same column.

That vetical line of mine contains four points, are on the same line, and so my interpretation.