Advent of Code - Day 6



Note by the Moderators: This topic is to talk about Day 6 of the Advent of Code.

For general discussion about the Advent of Code 2018 and links to topics of the other days, see this topic.

Advent of Code - Day 6 -old

Anybody do this yet?

I can’t even figure out how they want me to build the areas. The description just leaves me like… :dizzy_face:


A certain square belongs to point X, if there is no other point Y that is closer than X using Manhattan distance.


I struggled with this one more than I’m willing to admit, and ultimately made a brute-force solution which works reasonably fast and is not very ugly. You can find it here.


Today was a bit tricky… I scraped my elixir solution and wrote one in javascript (which would be trivial to translate to Elixir now when I know how).

Part 1.
I implemented a “flood fill” algorithm, relying on the fact that it is easy to enumerate all positions with distance N from a given position.

Part 2.
Step 1. Find the center of gravity
Step 2. ´Enumerate all positions with distance N from the center, count positions where the condition is true (sum all manhattan distances to the position). Continue to do this with distance N + 1, stop when the conditions fails for all positions in a level (N).


Finally I found the time to sit down and do day 6.

I’m not very happy with the code, as it is brute force.

Part 1 checks every square in a given bounding box for the nearest coordinate from the input, and returns a list of tuples, where the first element is the input coordinate and the second the actual field. Then I group by the input coordinate and reject those that are infinite (an area is classified as infinite if the line to the “owner” is orthogonal to the edge this field is on). Then just map the length of the lists and find the maximum…

Part 2 is even more brute force. It scans all coordinates in the bounding box, calculates the sum of the distances and rejects all fields that have a sum greater than or equal the threshold.

TIL: Enum.group_by has a third argument, that can be used to alter the value inserted in the list. Such that Enum.group_by(input, key_fun, val_fun) is equivalent to input |> Enum.group_by(key_fun) |>{k, values} -> {k,, val_fun) end)}) |> Enum.into(%{}), well roughly. I think you see what I mean…

My code is available at gitlab, as usual:


Today’s challenge is rough. I’ve just completed part 1 after a lot of head scratching before I realised that my issue was in determining what were the infinite coordinates. I too had to resort to a brute-force approach so it will be really interesting to look at some of the other solutions posted as well as José’s code from his stream tomorrow.

I’m going to have a quick look at part 2 but that may become a weekend task. Along with the other ones. This could be where I start to fall behind a bit.

Edit 22 minutes later… Part 2 was way, way easier for me. Fortunately!

My solution is at:

I’m not overly proud of the code but it’s late and I need some sleep!


This one wasn’t pretty. Both solutions were rather brute force, but they completed quickly enough.


I thought I was doing okay until I went to submit my answer. I can’t figure out what I’m doing wrong, I can get the example/test data to work but not my input. Obviously I’m doing something stupid, but can’t see what.

Can anyone else see what the heck I’m doing wrong?


Looking at your code, it seems you assume that the finite region is a square, when it’s in fact a rectangle. So instead of finding one min-max pair, like you do in line 24, you need two pairs ((xmin, xmax) and (ymin, ymax)), and eliminate coordinates where x == xmin or xmax, or y == ymin or ymax.