Advent of Code 2020 - Day 17

Interesting twist in part 2. I had expected the number of cycles to be hugely increased.

I did not try to make a general solution that would share most code between part 1 and part 2. Instead, I copied the my part 1 solution and added another dimension. No further optimizations were needed since both parts run in about 3.2 seconds on my computer.

Here is my solution.

Is there a mistake in the initial state of the example or am I not getting it? E.g. why does -1, 1, -1 (top left corner in z=-1) get active after 1 cycle? The only active neighbour in the initial state was 0, 1, 0 (top middle), no?

They updated the text slightly after a while since a lot of people got confused by the example (me included). In short, the top left coordinate in the z0 layer is not the same in each iteration and moves around depending on where there are active satellites.

Struggled for about an hour trying to make sense of the examples (and thought they meant the space wrapped around which created a real headache with a growing universe ).

I settled for storing the active satellites in a map, keyed on coordinates. Then I ran each iteration and checked all positions within my active state plus one in each direction.

Here is my solution.

Part 2 was simply extending part 1 with an extra dimension so only posted that.

@bjorng nice to use Stream.iterate() |> Enum.drop(6), also realised reading your code that I was a bit silly to filter my Map and use Enum.count since I also only store the active satellites in my map.

Finally ! Finally My huge copy and paste skills could be used at their full potential for part 2.

My solution finishes under 2 seconds for part 2 so I am satisfied with it. For each iteration I generate a list of changes that I apply to the map all at once at the end of each turn. Remembering day 11, this technique does not improve performance drastically compared to directly putting changes into a copy of the map directly.

But today as the “domain” (that is how I called the bounds, I was missing the “bounds” word) keeps growing, it is faster to recalculate max bounds instead of scanning the whole new map ; the changes is already a list and is smaller.

However, I use this code (this is for part 1). The 2nd argument is the coordinates for a cube that has just been activated.

  defp expand_domain({min_x, max_x, min_y, max_y, min_z, max_z}, {x, y, z}) do
    {min(min_x, x), max(max_x, x), min(min_y, y), max(max_y, y), min(min_z, z), max(max_z, z)}
  end

This is a lot of calls to min/1 and max/1 for each change. I guess using pattern matching and recursion until the domain includes the coordinates of an active point could be better.

Today, seeing that part 2 was not “run 3’000’000 cycles” was a bit disappointing but also a relief

my solution

Read it over and over… nope, I still don’t get it. The top left coordinate of the z0 layer has 1 active satellite in the “before any cycles”. But it is active in the “After 1 cycle”. So you’re saying they move around. Where is that movement described?

They patched the text just above the graphs and added (and the frame of view follows the active cells in each cycle) as lots of people got confused.

I ended up ignoring the graphs all together as they didn’t really help me in any way.

Oh boy, I get it now! I was looking for something in the instructions, but it’s how the examples are displayed. The frame of view is moving!
I could have ignored the examples but it bothered me that my understanding after which I write the algorithm wouldn’t even comply with the example. Alright… let’s see where to find the motivation to solve this now…

We may have to found a way to generate/generalize this to n-dimension, this one was just to ensure everyone is ready, I think.

Took sometime to make it generic, so it can work with n dimensions (not really required though). Relatively easy part two this time