AdventOfCode/2020/elixir/day10
Adam Millerchip 39c28b5897 Move 2020 elixir solutions to 2020/elixir in prep for zig 2022-08-11 16:22:22 +09:00
..
README Move 2020 elixir solutions to 2020/elixir in prep for zig 2022-08-11 16:22:22 +09:00
day10part1.exs Move 2020 elixir solutions to 2020/elixir in prep for zig 2022-08-11 16:22:22 +09:00
day10part2-refactored.exs Move 2020 elixir solutions to 2020/elixir in prep for zig 2022-08-11 16:22:22 +09:00
day10part2.exs Move 2020 elixir solutions to 2020/elixir in prep for zig 2022-08-11 16:22:22 +09:00
input Move 2020 elixir solutions to 2020/elixir in prep for zig 2022-08-11 16:22:22 +09:00

README

Day 10 Notes

+--------+
| Part 1 |
+--------+

$ elixir day10part1.exs
2450

Thoughts:

Noticed that the questions rely on you finding some insight into the data, rather than just
implementing exactly what the instructions say.

In this case, we just need to sort the data, and compute the difference between all the pairs.


+--------+
| Part 2 |
+--------+

$ elixir day10part2.exs
32396521357312

Thoughts:

Fudge me this took me a long time (hours, including a walk in the park...)

I spent far too long trying to find a mathematical answer based on combinations, and went down
another rabbit hole identifying the "removable" items and then trying to calculate the answer
based on that information.

Turns out the trick I was missing is graph theory.

Finally, after drawing out the example on paper, I realised that the number of combinations
forms a directed graph, where the weight of each node inherits the weight of all its parents.
For the example case (excuse my ascii drawing skills):

0(1)-1(1)-4(1)-5(1)-|
            \ \ |   |
             \ 6(2) |
              \ |   |
               7(4)-|
                |
               10(4)-11(4)
                   \ |
                     12(8)-18(8)-19(8)

So just need to make an algorithm that builds this graph, by iterating the sorted list
and checking the next 3 elements, keeping track of the weights as we go. It's actually simpler
than that, because we don't need to keep the connections around, just the weightings for each node.

Finally, the weight of the max joltage adapter is the answer.

** Update **

I added day10part2-refactored.exs, which contains a commented and arguably easier to understand
version that uses Enum.reduce instead of so much recursion. However, in benchmarks it was
negligibly (~1 microsecond) slower, so I decided to leave the original version in place.

+------------------+
| Overall Thoughts |
+------------------+

Part 1 was very easy, part 2 was fiendish. Glad this wasn't an interview question. Sometimes my
brain just doesn't process certain types of problem. This was one of them. Once I made the
connection to a weighted graph it was fine.