Andrew Fontaine

Advent of Code 2019: Day 12

2019-12-13T20:49:00+00:00

I see I am trying not to crash today. I’ve been given some pretty simple instructions on how to handle tracking how gravity applies to the moons, so first I’ll go about implementing that. A moon can be a map that contains its position and its velocity: %{p: {0, 0, 0}, v: {0, 0, 0}}

  defp apply_velocity(%{p: {x1, y1, z1}, v: {x2, y2, z2} = v}) do
    %{p: {x1 + x2, y1 + y2, z1 + z2}, v: v}
  end

  defp set_velocity(%{p: p1, v: v1}, %{p: p2}) do
    %{p: p1, v: apply_gravity(v1, gravity_diff(p1, p2))}
  end

  defp apply_gravity({x1, y1, z1}, {x2, y2, z2}) do
    {x1 + x2, y1 + y2, z1 + z2}
  end

  defp gravity_diff({x1, y1, z1}, {x2, y2, z2}) do
    {gravity_diff(x1, x2), gravity_diff(y1, y2), gravity_diff(z1, z2)}
  end

  defp gravity_diff(p1, p2) when p1 > p2, do: -1
  defp gravity_diff(p1, p2) when p1 == p2, do: 0
  defp gravity_diff(p1, p2) when p1 < p2, do: 1

apply_gravity/2 takes the positions of 2 moons, and computes how gravity affects the velocity of the first moon. gravity_diff/2 takes two positions and calculates how gravity affects the first moon by returning a differential, such as {-1, 1, 0}. set_velocity/2 uses the above two functions to apply gravity to the first moon, as computed above, and apply_velocity/1 alters the given moon’s position by its velocity. All that’s left is to chunk the moons through it for 1000 steps and calculate the final energy output.

  def p1(), do: s1(input_stream(), 1000)

  def s1(stream, x) do
    moons = Enum.map(stream, &parse/1)

    Range.new(1, x)
    |> Enum.reduce(moons, fn _, moons -> run_step(moons) end)
    |> Enum.map(fn %{p: {x1, y1, z1}, v: {xv, yv, zv}} ->
      (abs(x1) + abs(y1) + abs(z1)) * (abs(xv) + abs(yv) + abs(zv))
    end)
    |> Enum.sum()
  end

  defp run_step(moons) do
    moons
    |> Enum.map(fn moon ->
      Enum.reduce(moons -- [moon], moon, fn m1, m2 ->
        set_velocity(m2, m1)
      end)
    end)
    |> Enum.map(&apply_velocity/1)
  end

one done.

Puzzle 2

Oh jeez… Time to discuss time complexity. The puzzle clearly states that I probably can’t just straight run the simulation for that long, which is too bad, because now I need to research what I can do instead. Well, for starters, the dimensions are independent of each other, so I could theoretically compute all the moon’s x, y, and z position cycles separately, which gives 3 cycles, the x cycle, the y cycle, and the z cycle. After that, I just need to find the number of cycles it takes for those sub-cycles to line up.

Again, too big of a number to just continually add numbers to until I figure it out. As with all my greatest works, the next step is to Google the problem.

Googling says something about the least-common multiple (LCM), which rings a bell. What does Wikipedia say? “It is the smallest positive integer that is divisible by each of them.” BOOM that is exactly what I’m looking for!

Let’s say I have 2 cycles, 2 and 5. The least common multiple here is 10. It’s also very clearly the first number where the cycles line up!

OK, so I have my cycles, all that’s left is to compute the LCM for the three of them. The easiest formula involves the greatest common divisor (GCD). Fortunately for us, there is Integer.gcd/2. Oh, it only takes 2 numbers… back to the Wikipedia page! Wikipedia suggests that lcm(a, lcm(b, c)) == lcm(lcm(a, b), c), so I can compute the LCM of one pair and use it to compute the LCM of the pair and another and so on until I’m done. All that’s left is to compute! I am adjusting the format of data to be three lists of tuples, one per axis, where the first element of the tuple is the position and the second element is the velocity, which means I need some different functions for computing movements.

  def p2(), do: s2(input_stream())

  def s2(stream) do
    moons = Enum.map(stream, &parse/1)

    moons
    |> Enum.map(fn %{p: {x, y, z}, v: {xv, yv, zv}} -> [{x, xv}, {y, yv}, {z, zv}] end)
    |> Enum.reduce([[], [], []], fn [x, y, z], [xs, ys, zs] ->
      [[x | xs], [y | ys], [z | zs]]
    end)
    |> Task.async_stream(fn ps ->
      1
      |> Stream.iterate(&(&1 + 1))
      |> Enum.reduce_while(ps, fn c, moons ->
        moons = run_step(moons)

        if moons == ps do
          {:halt, c}
        else
          {:cont, moons}
        end
      end)
    end)
    |> Stream.map(fn {:ok, x} -> x end)
    |> Enum.reduce(1, fn x, y -> div(x * y, Integer.gcd(x, y)) end)
  end

  defp apply_velocity({p, v}), do: {p + v, v}

  defp set_velocity({p1, v1}, {p2, _v2}) do
    {p1, apply_gravity(v1, gravity_diff(p1, p2))}
  end

  defp apply_gravity(p, v), do: p + v

For speed, I can use Task.async_stream/3 to compute the cycles in parallel, and then funnel them into a final Enum.reduce/3 to compute the least common multiple! The result is: huh, a very, very, humungous number. No wonder I had to put all this work into a math-y solution.

Conclusion

To be honest, I don’t really like these puzzles where there’s a “trick” to them. If I didn’t Google or knew about least-common multiples, I’d be stuck staring at this puzzle for a very long time. I could’ve maybe pencilled out the idea of a solution, but would’ve needed to look up some formulae on how to compute the thing. Which is to say, it’s not so much about building a solution but finding one. Anyway, maybe day 13 will be more my style?

Advent of Code 2019: Day 11

2019-12-12T18:55:00+00:00

More intcode problems! First, I’ll tune up the intcode computer a little bit. I noticed day 9 ran a little slow, and I think it’s because the program is a list. In elixir, lists are implemented as linked lists, which don’t have the best access time, as the list needs to be iterated through to find the element at the given index, so read-heavy operations, like the intcode computer, can suffer, especially as the intcode computer appends a memory space at the end of the list to use as variables. Iterating through 1000 items every time I need to read an element there can take its toll! I can do better.

I also wasn’t pleased with how the list had to expand when writing to an address outside of the bounds of the current memory space. I wanted something that didn’t need to grow as much while also providing an easy way of returning a default for address that I don’t know about yet. A Map is perfect for this!

First, I need to modify the struct and Intcode.new/3 to handle a program being a map.

  defstruct program: %{},
            position: 0,
            input: [],
            output: [],
            offset: 0

  def new(program, input \\ [], output \\ []),
    do: %__MODULE__{
      program:
        program |> Enum.with_index() |> Enum.map(fn {p, i} -> {i, p} end) |> Enum.into(%{}),
      input: input,
      output: output
    }

The keys of the map are the addresses of my program, and their values are the values of the program, turning a program like [1, 0, 0, 0, 99] into %{0 => 1, 1 => 0, 2 => 0, 3 => 0, 4 => 99}.

After updating all the Enum.at(program, position, 0) calls to Map.get(program, position, 0), and cleaning up that store function to remove the memory extending code, and there are significant speed ups, going from just over 2 minutes for Day 9 Part 2 to just over 2 seconds!

This clean-up wasn’t possible without my existing test cases, which did need to be updated slightly, going from assert ^expected = c.output to assert ^expected = Map.values(c.output), but all the tests passed and the computer was much faster

As for the actually problem, I created one task to handle the intcode computer, the robots “brain”, and one to handle its movements. The robot was taught to talk to the brain, and all that was left was to await the result.

  def p1(),
    do:
      input_stream()
      |> p(0)
      |> Map.keys()
      |> length()

  defp p(stream, input) do
    robot =
      Task.async(fn ->
        loop(%{direction: :up, panel: {0, 0}, panels: %{}, action: :paint, computer: nil})
      end)

    computer =
      Task.async(fn ->
        stream
        |> Enum.at(0)
        |> String.split(",")
        |> Enum.map(&String.to_integer/1)
        |> Intcode.new(:server, robot.pid)
        |> Intcode.run_all()
      end)

    send(robot.pid, {:computer, computer.pid})
    send(computer.pid, {:message, input})

    robot
    |> Task.await()
    |> Map.get(:panels)
  end

  defp loop(state) do
    receive do
      :halt -> state
      {:message, i} -> state |> handle_message(i) |> loop()
      {:computer, i} when is_pid(i) -> loop(%{state | computer: i})
    end
  end

loop/1 takes the starting state of the robot, and then I send the computer and the robot their starting messages. When the robot receives :halt, it means the computer has finished its work, and I can return the final state. Receiving {:computer, i} stores the PID of the computer so the robot can send it further data. When the robot receives {:message, i}, I need to update the state and loop again.

  defp handle_message(%{action: :paint, panel: panel, panels: panels} = state, i) do
    %{state | action: :turn, panels: Map.put(panels, panel, paint(i))}
  end

  defp handle_message(%{action: :turn, direction: d, panel: p, computer: c} = state, i) do
    d = turn(d, i)
    state = %{state | action: :paint, direction: d, panel: move(d, p)}

    state.panels
    |> Map.get(state.panel, :black)
    |> colour()
    |> (&send_colour(c, &1)).()

    state
  end

  defp send_colour(computer, colour), do: send(computer, {:message, colour})

By pattern matching on the :action the robot is on, I can decided which is the appropriate action to take. :paint adds the current panel to the map of panels that I have been painted with the colour that it has been painted.

  defp paint(0), do: :black
  defp paint(1), do: :white

I also update the action to :turn so the next message received runs the next function.

The :turn action is a little bigger. It has to

turn the robot,
move the robot, and
send the brain the colour of the panel it just moved to.

The first two are handled by 2 simple functions that match on the direction and return the updated :direction and :panel.

  defp turn(:up, 0), do: :left
  defp turn(:up, 1), do: :right
  defp turn(:right, 0), do: :up
  defp turn(:right, 1), do: :down
  defp turn(:down, 0), do: :right
  defp turn(:down, 1), do: :left
  defp turn(:left, 0), do: :down
  defp turn(:left, 1), do: :up

  defp move(:up, {x, y}), do: {x, y + 1}
  defp move(:right, {x, y}), do: {x + 1, y}
  defp move(:left, {x, y}), do: {x - 1, y}
  defp move(:down, {x, y}), do: {x, y - 1}

The colour the panel is on is gotten by checking the map of painted panels for a colour, and returning the default of :black if there isn’t one.

  defp colour(:black), do: 0
  defp colour(:white), do: 1

This continues on until the computer is done. For puzzle one, returning the number of panels I’ve painted is as simple as returning the number of keys in the :panels map. one done!

Puzzle 2

Part 2’s only extra work is to print the painted panels. By reusing the code from day 8, it’s a simple extension to draw the panels.

  def p2(), do: input_stream() |> p(1) |> draw()

  defp draw(panels) do
    [{x1, y1}, {x2, y2}] =
      panels
      |> Map.keys()
      |> Enum.reduce([{0, 0}, {0, 0}], fn {x, y}, [{x1, y1}, {x2, y2}] ->
        [{min(x, x1), min(y, y1)}, {max(x, x2), max(y, y2)}]
      end)

    Enum.map(Range.new(x1, x2), fn x ->
      Enum.map(Range.new(y1, y2), fn y ->
        panels
        |> Map.get({x, y}, :black)
        |> write()
      end)
    end)
    |> Enum.each(&IO.puts/1)
  end

  defp write(colour), do: IO.ANSI.format_fragment([colour, "█", :reset])

I do need to check and make sure I draw all the panels, so I need to quickly find the bounds of the painted panels, then iterate over the panels to draw out the ship’s new registration code!

That’s another !

Conclusion

Elixir’s easy ability to have tasks talk to each other made today a lot easier than it potentially could’ve been. I think the next time a problem like this comes around, I’ll be thinking on how to generalize this runner into something reusable. Also Lists in Elixir can be sneakily expensive, so if you aren’t using a majority of the list, reach for a Map instead.

Advent of Code 2019: Day 10

2019-12-11T18:31:00+00:00

Cool, asteroids! Not cool, trigonometry!

Let me just search my brain for math I haven’t used in years, no problem at all. Let’s see… if I have one asteroid, x, and two others, y and z, and the angle between x and y is the same as x and z, the only one of y and z is visible. For the first problem, calculating the angles between all the asteroids and eliminating duplicates will show how many other asteroids are visible from a single asteroid.

To calculate the angle, I can use Erlang’s :math.atan2/2, and I want to use the non-strict Enum.uniq/1 that uses a softer equality check for floating point issues. For parsing, I just collapse the whole field into a single list of points where asteroids exist. I don’t care about the empty space.

  def p1(), do: s1(input_stream())

  def s1(stream) do
    asteroids = parse(stream)

    asteroids
    |> Enum.map(fn point ->
      count_visible_asteroids(point, asteroids -- [point])
    end)
    |> Enum.max()
  end

  defp parse(stream) do
    stream
    |> Enum.map(&String.graphemes/1)
    |> Enum.with_index()
    |> Enum.reduce([], fn {row, y}, asteroids ->
      row
      |> Enum.with_index()
      |> Enum.reduce([], fn
        {".", _x}, ast -> ast
        {"#", x}, ast -> ast ++ [{x, y}]
      end)
      |> Kernel.++(asteroids)
    end)
  end

  defp count_visible_asteroids({x1, y1}, asteroids) do
    asteroids
    |> Enum.map(fn {x2, y2} ->
      :math.atan2(y2 - y1, x2 - x1)
    end)
    |> Enum.uniq()
    |> length()
  end

one done!

Puzzle 2

Part 2 reminds me of day 9 from last year, with those elves playing games and making bets, always getting into trouble. To calculate the 200th destroyed asteroid, I can use Stream.cycle/1 and Enum.reduce_while/3 to infinitely iterate through the computed angles, blasting at asteroids until I destroy 200. This has the added benefit of always destroying an asteroid in each loop, not wasting cycles on angles that don’t have asteroids in them.

Using Enum.group_by/2, I can create a map where the keys are angles and the values are the asteroids at that angle, sorted by distance. Then, I can take the keys and construct a list of angles that starts at π/2, decreasing until 0 and starting over at 2π. The list, then, is ordered as [π/2, .., 0, 2π, .., π/2). Cycling over that infinitely quickly gives me the 200th destroyed asteroid!

Because Enum.group_by/2 is very strict about its key equality checks, angles that are (essentially) the same will differ at the 14th decimal point or so, causing extra asteroids to be destroyed in a single pass. The easiest way to fix that is to floor all the angles with a precision of 13. Thus, the final solution is:

  def p2(), do: s2(input_stream())

  def s2(stream) do
    asteroids = parse(stream)
    base = {x1, y1} = find_base_location(stream)

    grouped_asteroids =
      asteroids
      |> Kernel.--([base])
      |> Enum.group_by(fn {x2, y2} ->
        case :math.atan2(-1 * (y2 - y1), x2 - x1) do
          a when a < 0 -> a + 2 * :math.pi()
          a -> a
        end
        |> Float.floor(13)
      end)
      |> Enum.map(fn {angle, asteroids} ->
        {angle, Enum.sort_by(asteroids, &distance(base, &1))}
      end)
      |> Enum.into(%{})

    {starting, ending} =
      Map.keys(grouped_asteroids)
      |> Enum.sort(&Kernel.>=/2)
      |> Enum.split_with(fn x -> x <= Float.floor(:math.pi() / 2, 13) end)

    {x, y} =
      starting
      |> Enum.concat(ending)
      |> Stream.cycle()
      |> Enum.reduce_while({0, base, grouped_asteroids}, fn
        _a, {200, last, _asteroids} -> {:halt, last}
        a, {c, last, asteroids} -> pop_asteroid(a, c, last, asteroids)
      end)

    x * 100 + y
  end

  defp find_base_location(stream) do
    asteroids = parse(stream)

    asteroids
    |> Enum.max_by(fn point ->
      count_visible_asteroids(point, asteroids -- [point])
    end)
  end

  defp count_visible_asteroids({x1, y1}, asteroids) do
    asteroids
    |> Enum.map(fn {x2, y2} ->
      :math.atan2(y2 - y1, x2 - x1)
    end)
    |> Enum.uniq()
    |> length()
  end

  defp distance({x1, y1}, {x2, y2}) do
    :math.pow(:math.pow(x2 - x1, 2) + :math.pow(y2 - y1, 2), 0.5)
  end

  defp pop_asteroid(angle, c, last, asteroids) do
    roids = Map.get(asteroids, angle, [])

    if roids == [] do
      {:cont, {c, last, asteroids}}
    else
      [last | roids] = roids
      asteroids = Map.put(asteroids, angle, roids)

      {:cont, {c + 1, last, asteroids}}
    end
  end

Big takeaways are that:

Floating point numbers are imprecise and must always be accounted for, especially when handling irrational numbers.
This is the distance calculated using the fundamentals of Pythagorean theorem, not the Manhattan distance (from day 3).
Stream.cycle/1 and Enum.reduce_while/3 are powerful tools that allow looping over a list “infinitely”. In fact, a lot of the Enum’s _while methods are really powerful for this reason.

Conclusion

It took me a long time and lots of annoying print debugging to realize that it was floating points that were causing my issues picking up the wrong 200th asteroid. Those pesky elves should maybe stop gambling so much

Advent of Code 2019: Day 9

2019-12-10T16:41:00+00:00

As of today, I’ve beaten my previous year’s record (by one ), but, oh, was it a struggle. The task today is to boost a distress signal to discover what trouble those elves are up to now. First step is to add another parameter mode to the intcode computer! I need to add an offset value to the computer to keep track of the relative mode’s base offset, and add some ways to read the memory utilizing this parameter mode.

  defstruct program: [],
            position: 0,
            input: [],
            output: [],
            offset: 0

  defp parameter(0, x, prog, _computer), do: Enum.at(prog, x, 0)

  defp parameter(1, x, _prog, _computer), do: x

  defp parameter(2, x, prog, %__MODULE__{offset: offset}), do: Enum.at(prog, x + offset, 0)

Notice that I have to pass the computer struct into all of these functions so that I can access the offset in the new mode. I think I could alter this here to drop the prog parameter and pull it from the computer struct as well, but I have some other plans to tune up this computer.

Next, I need to augment writing values to the memory that uses this new mode.

  defp store(prog, pos, v, m, computer) do
    address =
      if m == 2 do
        computer.offset + Enum.at(prog, pos, 0)
      else
        Enum.at(prog, pos, 0)
      end

    prog =
      if length(prog) < address do
        prog ++ List.duplicate(0, address - length(prog))
      else
        prog
      end

    List.update_at(prog, address, fn _ -> v end)
  end

If the length of the program currently is shorter than the address I am trying to write to, I should extend the program’s memory to include that new address. Then, I update the program as normal.

I also need to add a new op-code to handle changing the base offset.

  def op(computer, [_a, _b, c, 0, 9]), do: {:ok, shift_offset(computer, c)}

  defp shift_offset(%__MODULE__{program: prog, position: pos, offset: offset} = computer, m) do
    shift = parameter(m, Enum.at(prog, shift(pos, 1), 0), prog, computer)
    %__MODULE__{computer | offset: shift(offset, shift), position: shift(pos, 2)}
  end

And I should be good to go! Wait…

That’s not good, the opcode 209 is failing Maybe I am not adding enough memory when I extend my list? I’ll just add one, off by one errors are classic.

  defp store(prog, pos, v, m, computer) do
    address =
      if m == 2 do
        computer.offset + Enum.at(prog, pos, 0)
      else
        Enum.at(prog, pos, 0)
      end

    prog =
      if length(prog) < address do
        prog ++ List.duplicate(0, address - length(prog) + 1)
      else
        prog
      end

    List.update_at(prog, address, fn _ -> v end)
  end

Run it again!

203!? Well… At least the result is different. Maybe… more memory?

  defp store(prog, pos, v, m, computer) do
    address =
      if m == 2 do
        computer.offset + Enum.at(prog, pos, 0)
      else
        Enum.at(prog, pos, 0)
      end

    prog =
      if length(prog) < address do
        prog ++ List.duplicate(0, address)
      else
        prog
      end

    List.update_at(prog, address, fn _ -> v end)
  end

No more trying to be safe, I’ll just throw as much memory as I can possibly need at this thing. This time I’m serious.

Thank goodness it worked!

There’s no puzzle 2 section today, because puzzle 2 was solved by using the newly-constructed intcode computer and no other alterations. It’s not often that the first puzzle is the challenging one. I think I’ll have to use this more going forward, so I plan on cleaning it up. I saw someone suggest a Map instead of a list, so I think I will try that out. This is likely to be a “sparse list”, or a list where a majority of indices in the list are unused, and I can get rid of my funky memory growth code.

Conclusion

Debugging this was quite hard, and I didn’t get a chance to really dive into debugging in Elixir. Fortunately, just throwing memory at the problem fixed it! My next step so to clean this code up, and add some debug level logs to help solve any issues that come up later. I also have a pretty good set of test cases to ensure my refactoring goes smoothly, but it didn’t help me figure out my memory growth issue. It may read short, but it took me pretty much all day to figure that one out

Advent of Code 2019: Day 8

2019-12-09T16:08:00+00:00

Saving a mars rover for the elves today! Why do they have to send the password as an image though? Just send me a text, jeez! Anyway, first step is to check and make sure the image was fully received. I can use Stream.chunk_every/2 to turn my list of digits to a list of layers. The only difference is that Stream versions of Enum functions return Streams that are lazily evaluated instead of iterating through the list all at once.

  defp parse_input() do
    input_stream()
    |> Enum.at(0)
    |> String.graphemes()
    |> Stream.map(&String.to_integer/1)
  end

  defp parse_layers(stream, x, y), do: Stream.chunk_every(stream, x * y)

All that’s left is to find the layer that has the least number of 0s, and return the checksum.

  def p1() do
    layer =
      parse_input()
      |> parse_layers(25, 6)
      |> Enum.min_by(&count(&1, 0))

    count(layer, 1) * count(layer, 2)
  end

  defp count(image, x) do
    Enum.count(image, &Kernel.==(&1, x))
  end

done!

Puzzle 2

I guess I have to display the image to get the password now. A simple extension on the original problem. The image format is unnecessarily complex as well (those pesky elves). The plan is to look at a pixel in each layer, and find the first pixel that is either 0 (black) or 1 (white), ignoring 2s. I can use Stream.zip/1 to merge the list of layers to a list of pixels, and Enum.find/2 to find the first pixel that matches the above.

  def p2() do
    parse_input()
    |> parse_layers(25, 6)
    |> Stream.zip()
    |> Stream.map(&Tuple.to_list/1)
    |> Task.async_stream(fn layer ->
      Enum.find(layer, fn pixel -> pixel == 0 or pixel == 1 end)
    end)
    |> Stream.map(fn {:ok, p} -> p end)
    |> parse_image(25)
    |> Enum.each(&IO.puts/1)
  end

Then, once a single list of pixels is left, all that’s left is to map the image to pixels, chunk the pixels into rows, and display the image!

  defp parse_image(layer, x) do
    layer
    |> Enum.map(fn
      1 -> IO.ANSI.format_fragment([:white, "█", :reset])
      0 -> IO.ANSI.format_fragment([:black, "█", :reset])
    end)
    |> Enum.chunk_every(x)
  end

IO.ANSI.format_fragment/2 returns a charlist, a fundamental structure that is a big part of the speed of I/0 in Elixir and Erlang, and helps to keep Phoenix’s templates fast. Once each pixel is mapped to a charlist and chunked into rows, all that is left is to print each row, with |> Enum.each(&IO.puts/1). Then, the image can be displayed!

That’s done as well!

Conclusion

Normally, I dislike writing visualizations, but between IO.ANSI.format_fragment and I/O charlists, printing out the password in a readable format was very straightforward. No tests today either, as this was a nice Sunday puzzle.

Advent of Code 2019: Day 7

2019-12-09T03:20:00+00:00

More intcode computing! Without any modifications to the computer, and a quick search for an algorithm to make permutations, which, like, I just didn’t want to have to figure out, and I am ready to solve this.

  defp permutations([]), do: [[]]

  defp permutations(list),
    do: for(elem <- list, rest <- permutations(list -- [elem]), do: [elem | rest])

Once my permutations are generated, all that’s left is to amp things up.

  defp amplify([p], prog, i),
    do:
      run(prog, [p, i])
      |> (&List.first(&1.output)).()

  defp amplify([p | r], prog, i) do
    o =
      run(prog, [p, i])
      |> (&List.first(&1.output)).()

    amplify(r, prog, o)
  end

  defp run(program, input, output \\ []) do
    program
    |> Intcode.new(input, output)
    |> Intcode.run_all()
  end

Given a program and permutation of possible phase settings, run the 5 amplifiers, feeding the output of one into the input of the other. As there are 5! = 120 permutations that don’t affect each other, using Task.async_stream/3 is a great reason to play with asynchronous processing. It takes my list of permutations and runs each one as a task, streaming the results to the next step in the pipeline. All that’s left is to find the highest frequency.

  def p1() do
    input_stream()
    |> Enum.at(0)
    |> s1()
  end

  def s1(program) do
    program
    |> String.split(",")
    |> Enum.map(&String.to_integer/1)
    |> p(0..4, &amplify/3)
  end

  def p(program, phases, f) do
    phases
    |> Enum.to_list()
    |> permutations()
    |> Task.async_stream(
      fn frequencies ->
        f.(frequencies, program, 0)
      end,
      timeout: :infinity
    )
    |> Enum.map(fn {:ok, i} -> i end)
    |> Enum.max()
  end

I made the timeout here :infinity just in case these jobs took a lot longer than the default 5 seconds timeout (spoiler alert: they didn’t). That’s one in the bag!

Puzzle 2

Feedback looping!? I can definitely connect inputs and outputs better. Hmm… Processes are a fundamental part of Erlang and Elixir… I know! I’ll wrap my computer in a process and send/2 and receive/1 messages between two computers! I need to add a new input/2 that can handle if I’m supposed to receive input from somewhere else.

  defp input(%__MODULE__{program: prog, position: pos, input: :server} = computer, m) do
    receive do
      {:message, i} when is_integer(i) ->
        %__MODULE__{computer | program: store(prog, shift(pos, 1), i, m), position: shift(pos, 2)}

      {:output, o} when is_pid(o) or is_list(o) ->
        input(%__MODULE__{computer | output: o}, m)

      :halt ->
        input(computer, m)

      e ->
        {:error, "Received #{e}"}
    end
  end

My computer can now handle 3 different messages: :message, :output, and :halt. :message is used to send output from one computer that is meant as input for another. :output is used to set the output of a computer to something else (it gets used in the final solution). :halt is used to notify the output that the computer has finally finished, but the intcode computer doesn’t care about that, so I can loop and wait for a proper :message.

I need a new output/2 as well.

  defp output(%__MODULE__{program: prog, position: pos, output: out} = computer, m)
       when is_pid(out) do
    send(out, {:message, parameter(m, Enum.at(prog, shift(pos, 1)), prog)})
    %__MODULE__{computer | program: prog, position: shift(pos, 2)}
  end

  defp output(
         %__MODULE__{program: prog, position: pos, output: [out | _rest] = output} = computer,
         m
       )
       when is_pid(out) do
    Enum.each(output, fn out ->
      send(out, {:message, parameter(m, Enum.at(prog, shift(pos, 1)), prog)})
    end)

    %__MODULE__{computer | program: prog, position: shift(pos, 2)}
  end

I check to see if the output is a PID or list of PIDs (again, for later), and send it the output.

Finally, I need a new/1 that can accept setting the output, and a run_all/1 that will send the final :halt command.

  def new(program, input \\ [], output \\ []),
    do: %__MODULE__{program: program, input: input, output: output}

  def run_all({:halt, %__MODULE__{output: o}}) when is_pid(o), do: send(o, :halt)

  def run_all({:halt, %__MODULE__{output: [o | _r] = out}}) when is_pid(o),
    do: Enum.each(out, &send(&1, :halt))

I think if I knew this is where I’d end up, all intcode computers would be run asynchronously with this message passing scheme.

The solution, then, is simply to wire up my computers to talk to each other and gather the output.

  def p2() do
    input_stream()
    |> Enum.at(0)
    |> s2()
  end

  def s2(program) do
    program
    |> String.split(",")
    |> Enum.map(&String.to_integer/1)
    |> p(5..9, &feedback_loop/3)
  end

  defp feedback_loop(frequencies, program, i) do
    [f | frequencies] = Enum.reverse(frequencies)
    last = Task.async(fn -> run(program, :server) end)

    first =
      frequencies
      |> Enum.reduce(last, fn f, %{pid: pid} ->
        t = Task.async(fn -> run(program, :server, pid) end)
        send(t.pid, {:message, f})
        t
      end)

    send(last.pid, {:output, [first.pid, self()]})
    send(last.pid, {:message, f})
    send(first.pid, {:message, i})
    List.first(await_output())
  end

  defp await_output(o \\ []) do
    receive do
      {:message, i} when is_integer(i) -> await_output([i | o])
      :halt -> o
      _ -> await_output(o)
    end
  end

p/3 already runs everything in their own separate tasks, so setting the output of the last computer to self/1 is actually setting it to the PID of the asynchronous task. This makes each permutation run in its own isolated environment. Then, await_output/0 loops, receiving output from the fifth amplifier until it has halted, returning the last received number. I just have to send the first amplifier its starting signal (0) to start the feedback loop!

A sample image, taken from Erlang’s process observer, is below. My task is the node on the left, while each of the 5 intcode processes is represented on the right.

All that’s left is to run it, and that’s for me

Conclusion

This one was pretty easy because the power of the OTP made it easy. It didn’t take too much extra code to add the ability to run these asynchronously and talk to each other.

Advent of Code 2019: Day 6

2019-12-08T02:04:00+00:00

Today, I’m pretty much playing Kerbal Space Program and planning some orbital trajectories. As shown in the problem itself, a tree is the perfect way to represent the orbits, so building one shouldn’t be too hard.

  defp build_tree([], node), do: node

  defp build_tree(list, p) do
    connections = Enum.filter(list, &String.starts_with?(&1, p))

    list = Enum.filter(list, fn x -> x not in connections end)

    c =
      connections
      |> Enum.map(fn x -> x |> String.split(")") |> List.last() end)
      |> Enum.map(fn x -> build_tree(list, x) end)

    %{p: p, children: c}
  end

list here is the list of connections I’m given, in the form of AAA)BBB, and p is the object that I am finding satellites of. First, I find all the connections by filtering the list for lines that start with the payload, and then for each child I build a tree with that child as the root. Once all the lines are filtered out, the tree is complete.

The goal is to compute how many direct and indirect orbits there are. For an object, the total number of indirect and direct orbits is simply its depth in the tree, so the total number of orbits in the whole tree is the sum of the depth of each node. There is a lovely recursive solution for that.

  defp total_orbits(node, t \\ 0)
  defp total_orbits(%{children: []}, t), do: t

  defp total_orbits(%{children: c}, t) do
    c |> Enum.map(&total_orbits(&1, t + 1)) |> Enum.sum() |> Kernel.+(t)
  end

Print out the result and that’s one done.

Puzzle 2

I know where Santa is! Now to calculate the fewest transfers between him and me. If I reduce the tree to the smallest tree that contains both nodes, the depth of each node’s parent will add up to the number of transfers required to reach my destination.

First to minimize the tree. If any of a node’s children contain both the nodes I’m looking for, I search that child’s children and so on. To handle checking if a tree contains a node, I check if its subtree contains the node until there’s only one node left.

  defp contains?(%{p: p}, p), do: true
  defp contains?(%{children: [], p: _p}, _x), do: false
  defp contains?(%{children: c}, x), do: Enum.any?(c, &contains?(&1, x))

  defp minimize_tree(%{children: c} = node, a, b) do
    case Enum.find(c, fn x -> contains?(x, a) and contains?(x, b) end) do
      nil -> node
      tree -> minimize_tree(tree, a, b)
    end
  end

It’s not exactly the most computationally efficient method, as I am descending the depths of the tree a lot, but I was trying to finish this over lunch.

Once the smallest tree is found, I just need to calculate the depth of the node’s parents, which is very close to the above.

  defp depth(node, p, t \\ 0)
  defp depth(%{children: [], p: p}, p, t), do: t - 1

  defp depth(%{children: c}, p, t) do
    child = Enum.find(c, &contains?(&1, p))
    depth(child, p, t + 1)
  end

  defp total_moves(tree, a, b) do
    node = minimize_tree(tree, a, b)
    depth(node, a) + depth(node, b)
  end

And with that, the problem is solved! Two received.

Conclusion

Another day with no tests. I remember these tree algorithms from school, so I was confident in my solution. It is a touch slow, at around 1.5 seconds, which I find interesting. I am a little curious to try and find out what my bottleneck is here, but not enough to sit down and figure it out.

Advent of Code 2019: Day 5

2019-12-06T16:39:00+00:00

In which previous bad code shoots me in the foot.

This was a continuation of the puzzle from day 2. If you don’t recall, I made a small intcode computer that was able to add, multiply, and stop. I need to augment this computer by adding the ability to take input and produce output. I also need to handle “parameter modes” and expanded intcodes

First, I want to be able to handle expanded intcodes. I also wanted to ensure it is backwards compatible with day 2. intcodes are now 5 digit numbers, where the first three digits indicate the parameter mode for a given parameter and the final 2 digits are the operational code.

  def run(%{program: prog, position: pos} = computer) do
    code =
      prog
      |> Enum.at(pos)
      |> Integer.digits()
      |> pad_code()

    op(computer, code)
  end

  defp pad_code(code) do
    List.duplicate(0, 5 - length(code)) ++ code
  end

As leading zeros are not included when calling Integer.digits/2, I just pad them at the front once I have a list so [1, 0, 2] becomes [0, 0, 1, 0, 2]. This also makes the codes from day 2 into “expanded” codes, and things will continue to work. To handle parameter modes, I will create a helper function that checks the mode and returns the correct value for the parameter.

  defp parameter(0, x, prog), do: Enum.at(prog, x)

  defp parameter(1, x, _prog), do: x

  defp parameter(_, x, prog), do: parameter(0, x, prog)

A mode of 0 indicates the parameter is a pointer to somewhere else in the program, which is exactly how day 2 operated. A mode of 1 indicates that the value is the parameter.

Mode 0: A parameter of 3 means the value is found at index 3 of the program list, so I must find and return it.
Mode 1: A parameter of 3 means the value is 3, so I can return it immediately.

I added a default case that ensures the mode is 0 in case something goes wrong, but crashing here would probably be better. As these parameter codes also affected the output of an opcode, I created a helper to handling storing values (it would come in handy when handling input as well).

  defp store(prog, pos, v, m) do
    List.update_at(prog, parameter(m, pos, prog), fn _ -> v end)
  end

While I’m sure output would always be mode 0, it doesn’t hurt to handle it just in case there’s a throwaway value. The problem also doesn’t explicitly state one way or the other, so I’d rather be safe than sorry.

I’ll also make a small helper for shifting the position of the program, to cover all my bases.

  defp shift(pos, x), do: pos + x

Again, probably unnecessary but it felt right.

Now that I have a bunch of helpers, I’ll amplify my existing op/2 functions to handle the new modes with a new compute/3 method.

  def op(computer, [a, b, c, 0, 1]),
    do: {:ok, compute(computer, &Kernel.+/2, [a, c, b])}

  def op(computer, [a, b, c, 0, 2]),
    do: {:ok, compute(computer, &Kernel.*/2, [a, c, b])}

  defp compute(%__MODULE__{program: prog, position: pos} = computer, f, [m | modes] = args) do
    vals =
      modes
      |> Enum.with_index(1)
      |> Enum.map(fn {m, i} -> parameter(m, Enum.at(prog, pos + i), prog) end)

    prog = store(prog, pos + length(args), run(f, vals), m)

    pos = shift(pos, length(args) + 1)

    %__MODULE__{computer | program: prog, position: pos}
  end

  defp run(f, args) do
    apply(f, args)
  end

OK, so compute/3 is the big many-step process that should run the things:

Fetch the values for the parameters for the op-code
Run the provided elixir function for the op-code with the given parameters
Store the result in the appropriate location
Shift the program pointer the right number of steps
Return an updated %Intcode{} struct.

This is still compatible with the problem from day 2! Time for the new instructions.

Input and Output

I don’t like the idea of actually prompting for input and printing output, so I added some lists to keep track of it.

  defstruct program: [],
            position: 0,
            input: [],
            output: []

and alter new to allow the passing in of input

  def new(program, input \\ []), do: %__MODULE__{program: program, input: input}

At this point, I realized I’d have to pass input and output all around, and decided (after an hour of mulling it over), to just make some new methods for them specifically

  def op(computer, [_a, _b, c, 0, 3]),
    do: {:ok, input(computer, c)}

  def op(computer, [_a, _b, c, 0, 4]),
    do: {:ok, output(computer, c)}

  defp output(%__MODULE__{program: prog, position: pos, output: out} = computer, m) do
    output = out ++ [parameter(m, Enum.at(prog, pos + 1), prog)]

    pos = shift(pos, 2)

    %__MODULE__{computer | program: prog, position: pos, output: output}
  end

  defp input(%__MODULE__{program: prog, position: pos, input: [i | t]}, m) do
    prog = store(prog, pos + 1, i, m)
    %__MODULE__{program: prog, position: pos + 2, input: t}
  end

All that’s left is to update run_all to ensure I can access the output and do the puzzle!

  def run_all({:halt, computer}), do: computer

import AdventOfCode
alias AdventOfCode.Y2019.Utils.Intcode

aoc 2019, 5 do
  def p1(), do: compute([1])

  def compute(i) do
    input_stream()
    |> Enum.at(0)
    |> String.split(",")
    |> Enum.map(&String.to_integer/1)
    |> Intcode.new(i)
    |> Intcode.run_all()
    |> Map.get(:output)
  end
end

one done!

Puzzle 2

Oh wow more instructions! Let’s get hopping!

Jumps

To handle the jumps, I added a jump/4 function that checks if the provided function is true and jumps!

  def op(computer, [_a, b, c, 0, 5]),
    do: {:ok, jump(computer, c, b, &Kernel.!=/2)}

  def op(computer, [_a, b, c, 0, 6]),
    do: {:ok, jump(computer, c, b, &Kernel.==/2)}

  defp jump(%__MODULE__{program: prog, position: pos} = computer, a, b, f) do
    if f.(0, parameter(a, Enum.at(prog, pos + 1), prog)) do
      %__MODULE__{computer | position: parameter(b, Enum.at(prog, pos + 2), prog)}
    else
      %__MODULE__{computer | position: pos + 3}
    end
  end

Comparisons

Comparisons, thankfully, work exactly as the first two op-codes, so adding them is as simple as the following.

  def op(computer, [a, b, c, 0, 7]),
    do: {:ok, compute(computer, &Kernel.</2, [a, c, b])}

  def op(computer, [a, b, c, 0, 8]),
    do: {:ok, compute(computer, &Kernel.==/2, [a, c, b])}

After some quick testing, and more writing, puzzle 2 is done.

  def p2(), do: compute([5])

Conclusion

There were a number of hiccups along the way. Again, I started way too late. I also spent a very long time trying to make compute/3 handle all of my op-codes. I still think its possible, but I was running out of time and needed to get something done. I also misread a test case, so my first answer of Puzzle 2 was wrong, again staying up too late. The worst part is that my code worked correctly when I wrote it, and the bad test case made me change it. In the end, I was successful.

abound, and ready for the next day!

Advent of Code 2019: Day 4

2019-12-05T19:30:00+00:00

This one didn’t seem too bad, but I can’t help but feel there’s a “clever” solution that alludes me. Some sort of funky math theorizing that I just don’t know about.

Puzzle 1

Put on your hacker gloves, it’s time to crack some passwords!

Oh, you only want a count of possible ones? That shouldn’t be too hard.

First, a function to check if the digits/2 of the password match the rules.

  def p1_possible(y) do
    length(y) == 6 and Enum.sort(y) == y and check_doubles(y)
  end

While I feel like there should be some fancy way to check if doubles exist, I decided chunk_every/4 would work great here.

  defp check_doubles(y) do
    y
    |> Enum.chunk_every(2, 1, :discard)
    |> Enum.any?(fn [a, b] -> a == b end)
  end

Similar to yesterday’s puzzle, I am taking two adjacent digits and making sure they are equal. All that’s left is to count up the good ones.

  def compute_possibles([s, e]) do
    Enum.reduce(s..e, 0, fn x, acc ->
      y = Integer.digits(x)

      if p1_possible(y) do
        acc + 1
      else
        acc
      end
    end)
  end

Boom, HACKED

Puzzle 2

Puzzle 2 has a nice little spin on the original problem, declaring that there is definitely at least one set of just doubles in the password.

111111 is no good, as there isn’t a set of doubles all on its own
111122 is good, because the 22 is a double.

I can already re-use p1_possible/1, as all of those rules apply as well. To see if there is a unique set of doubles, I can use chunk_while/4 to only emit chunks when the current digit is different than the last one.

  defp check_unique_doubles(y) do
    y
    |> Enum.chunk_while(
      [],
      fn
        x, [] -> {:cont, [x]}
        x, [x | _t] = acc -> {:cont, [x | acc]}
        x, [_y | _t] = acc -> {:cont, acc, [x]}
      end,
      fn x -> {:cont, x, []} end
    )
    |> Enum.any?(fn x -> length(x) == 2 end)
  end

I also decided it would be easiest to use pattern matching in the anonymous function, to avoid any extra ifs or conds. I’m not really sure what the last parameter is for, titled after_fun. It says that it runs after iteration is done, but I don’t understand what the difference is between returning {:cont, element, acc} and {:cont, acc} is. Something to look into at a later time!

After that, I just need to check if any chunk has a length of 2.

The solution is the same as before, but with the new p2_possible/1 instead.

  def compute_possibles([s, e]) do
    Enum.reduce(s..e, 0, fn x, acc ->
      y = Integer.digits(x)

      if p2_possible(y) do
        acc + 1
      else
        acc
      end
    end)
  end

  def p2_possible(y) do
    p1_possible(y) and check_unique_doubles(y)
  end

Calculating… calculating… .20 seconds is pretty quick still! I’m pleasantly surprised. received.

Conclusion

I, uh, actually didn’t write any tests for this one. It was pretty straight-forward and I manged to solve each puzzle on the first try, which is always nice. I can’t help but think that there’s a better way to do this than brute-forcing things, but, hey, it finished really quick.

That’s all today! On to day 5!

Advent of Code 2019: Day 3.5

2019-12-04T18:38:00+00:00

After 3 puzzles, I am taking a look at how things are set up, and making a few tweaks.

Projections

My projections just do not work. It gets confused when trying to call :A on a test file, going to or making a source file instead of jumping to the appropriate puzzle file. To alleviate this, I needed to make some alterations:

diff --git a/.projections.json b/.projections.json
index 46d04f5..1ad0e62 100644
--- a/.projections.json
+++ b/.projections.json
@@ -1,29 +1,38 @@
 {
-  "lib/*.ex": {
-    "alternate": "test/{dirname}/{basename}_test.exs",
-    "type": "source",
+  "lib/mix/tasks/*.ex": {
+    "type": "task",
     "template": [
-      "defmodule {camelcase|capitalize|dot} do",
+      "defmodule Mix.Tasks.{camelcase|capitalize|dot} do",
+      "  use Mix.Task",
+      "  ",
       "end"
     ]
   },
-  "lib/*.exs": {
-    "alternate": "test/{dirname}/{basename}_test.exs",
+  "lib/Y*.ex": {
+    "alternate": "test/Y{dirname}/{basename}_test.exs",
     "type": "puzzle",
     "template": [
       "import AdventOfCode",
       "",
       "aoc {dirname}, {basename} do",
       "",
-      "  def p1(), do: nil",
+      "  def p1(), do: :not_solved",
       "",
-      "  def p2(), do: nil",
+      "  def p2(), do: :not_solved",
       "",
       "end"
     ]
   },
-  "test/*_test.exs": {
-    "alternate": "lib/{dirname}/{basename}.ex",
+  "lib/Y**/utils/*.ex": {
+    "alternate": "test/Y{dirname}/utils/{basename}_test.exs",
+    "type": "source",
+    "template": [
+      "defmodule AdventOfCode.Y{dirname}.{camelcase|capitalize|dot} do",
+      "end"
+    ]
+  },
+  "test/Y*_test.exs": {
+    "alternate": "lib/Y{dirname}/{basename}.ex",
     "type": "test",
     "template": [
       "defmodule {camelcase|capitalize|dot}Test do",

First, I added a new file type! task is to easily jump to or spin up any new mix tasks that I think I might need, which I will talk about below. Secondly, I moved all the source files to a utils directory. This is to keep the ability to :Esource 2020/new_file next year, while also fixing jumping from a test to a puzzle (jumping from a test to a source still works, too). Next, I updated puzzle to include the Y in the path name, so instead of jumping to Y2019/2, I can jump to 2019/2. I also updated the template so the functions return :not_solved (for the new mix task below). test was set up fine, no problems .

Mix tasks

As I mentioned previously, I wanted a mix task that would run and print a given solution. My friends, it is HERE!

defmodule Mix.Tasks.Solution do
  use Mix.Task

  def run(args) when args == [] do
    date = get_date()
    run([date.day, date.year])
  end

  def run([d] = args) when length(args) == 1 do
    run([d, get_date().year])
  end

  def run([d, y | _]) do
    if Code.ensure_loaded?(AdventOfCode.module_name(y, d)) do
      if function_exported?(AdventOfCode.module_name(y, d), :p1, 0) do
        Mix.shell().info("The solution for Y#{y}, D#{d}, P1 is #{AdventOfCode.p1(d, y)}")
      end

      if function_exported?(AdventOfCode.module_name(y, d), :p2, 0) do
        Mix.shell().info("The solution for Y#{y}, D#{d}, P2 is #{AdventOfCode.p2(d, y)}")
      end
    else
      Mix.shell().error("The solution Y#{y}, D#{d} is not available")
    end
  end

  defp get_date() do
    Application.load(:tzdata)
    :ok = Application.ensure_started(:tzdata)

    case DateTime.now("America/Toronto", Tzdata.TimeZoneDatabase) do
      {:ok, d} -> d
      _ -> Date.utc_today()
    end
  end
end

This task allows me to run mix solution [d [y]] to run the solutions for a given day and year. It is smart enough to check if a solution function exists by calling function_exported?/3 with my generated module name, and :p1 or :p2 for each puzzle, and nicely printing the results. If the module doesn’t exist, an error message is printed instead. I think this task needs some more work to clean it up, and maybe have a different message if the result is :not_solved, but it is good for now.