I would be interested to see your implementation of Performance.memoize()?
Do you need to do anything to avoid problems when running say unit tests across many days/years of problems? Say in my case whenever I run mix test, it actually runs all the tests for all the tests I’ve been playing. I’m wondering how you partition your cache?
My previous was meant to be a reply to antoine-duchenet
I’m obviously an idiot, I have clicked reply on his post twice and it doesn’t seem to cause a reply to his actual post, nor can I figure out how to delete this second comment??
I’m using ETS to memoize.
first I create a named ETS table
:ets.new(:my_table, [:named_table])
then the memoize function
def memoize(key, fun) do
case :ets.lookup(@table, key) do
[{^key, val}] -> val
[] -> fun.() |> tap(&:ets.insert(@table, {key, &1}))
end
end
which I use like this:
def count_stones(stone, n) do
memoize({stone, n}, fn ->
case blink(stone) do
[s1, s2] -> count_stones(s1, n - 1) + count_stones(s2, n - 1)
stone -> count_stones(stone, n - 1)
end
end)
end
I would be interested to see your implementation of Performance.memoize()?
Here it is :
defmodule Performance do
def memoize(key, f) do
with nil <- Process.get(key), do: tap(f.(), &Process.put(key, &1))
end
end
I’m only using this implementation for AoC exercises, I don’t use it in production. It uses the process dictionary, which will have flaws if you need to share this cache between multiple BEAM processes.
You can still wrap it in a agent or use ETS if you need concurrency, but I never needed concurrency to solve AoC challenges (IMHO, if you do, it probably means that you missed something more elaborate than raw concurrency 
).
Please note that this is a lazy solution, I could use a Map instead but this gives me a quick and dirty way to add a “global” (to the process) state that I can read and write anywhere !
I hate dynamic programming problems. Didn’t do anything interesting here. ETS for the memoization.
defmodule Day11 do
require Integer
@test "125 17"
@real File.read!(__DIR__ <> "/input.txt") |> String.trim()
@run1 25
@run2 75
defp rules(0), do: 1
defp rules(n) do
x = :math.log10(n) |> floor()
if Integer.is_odd(x) do
divisor = Integer.pow(10, div(x + 1, 2))
[div(n, divisor), Integer.mod(n, divisor)]
else
n * 2024
end
end
def run(mode) do
data = mode |> input() |> parse()
:ets.new(:memo, [:named_table, :set, :public])
part_1(data) |> IO.inspect(label: :part_1)
part_2(data) |> IO.inspect(label: :part_2)
:ets.delete(:memo)
end
defp input(:test), do: @test
defp input(:real), do: @real
defp input(_), do: raise("Please use :test or :real as modes to run.")
defp parse(input) do
input
|> String.split(" ", trim: true)
|> Enum.map(&String.to_integer/1)
end
defp part_1(stones) do
count_stones(stones, @run1)
end
defp part_2(stones) do
count_stones(stones, @run2)
end
defp count_stones(stones, runs) when is_list(stones) do
stones
|> Enum.reduce(0, fn stone, acc -> count_stones(stone, runs) + acc end)
end
defp count_stones(stone, runs) do
case :ets.lookup(:memo, {stone, runs}) do
[] ->
apply_rules(stone, runs) |> tap(fn res -> :ets.insert(:memo, {{stone, runs}, res}) end)
[{_, res}] ->
res
end
end
defp apply_rules(stones, 0) when is_list(stones), do: length(stones)
defp apply_rules(_, 0), do: 1
defp apply_rules(stones, runs) when is_list(stones) do
stones
|> Enum.reduce(0, fn stone, acc -> acc + count_stones(stone, runs - 1) end)
end
defp apply_rules(stone, runs) do
count_stones(rules(stone), runs - 1)
end
end
Day11.run(:real)
@antoine-duchenet re: not needing concurrency, it’s probably true, but I did test with splitting the stones into chunks to create worker pools in parallel and got 50-60% improvement in performance by :timer.tc excluding the time for input parsing and starting the ETS cache. So, not necessary but can still be useful.
For grins I also tested whether it made a difference what type of table ETS used (set, ordered set, or bag) and it did not seem to make a difference for my implementation. Ordered set may have trended a few percent slower but meaningfully so.