*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.*

*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â€¦

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) |> Enum.map({k, values} -> {k, Enum.map(values, 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. https://github.com/sorentwo/aoc_2018/blob/master/lib/aoc/day_06.ex

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.

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.