thanks 
corner counting is good now 
Ill look at your example, but now im trying to find the non math way to do it. I might just go back to the drawing board Or, just skip it. I have learned enough btw done thanks for tolerating my grave digging 
i found out btw that the alternative approach was way more complex and didnt work the same on small inputs vs complex inputs. So i dropped digging more into it (i always begins with the simplest example and get it to work for all inputs, so when i suddenly get discrepancy for a larger input, I havent solved it and scraps it)
jarlah
1
bjorng
Erlang Core Team
No, nothing’s hiding here. 
My code connects all adjacent pieces of the fence. diff represents on which side of the plot the fence is located (above, below, left, or right). If the fence is above or below I want to group this plot with all plots on the same row, otherwise I want to group plots in the same column.
For example, take the e-shaped region in the puzzle descripton. Enum.group_by/3 will produce the following groups for the region of E plots:
%{
{{-1, 0}, 0} => [1, 2, 3, 4], # The fence below row 0, columns 1..4
{{-1, 0}, 2} => [1, 2, 3, 4], # The fence below row 2, columns 1..4
{{-1, 0}, 4} => [0, 1, 2, 3, 4], # The fence below row 4
{{0, -1}, 0} => [1, 3], # The fences right of column 0, rows 1 and 3
{{0, -1}, 4} => [0, 2, 4], # The fences right of column 4, rows, 0, 2, 4
{{0, 1}, 0} => [0, 1, 2, 3, 4],
{{1, 0}, 0} => [0, 1, 2, 3, 4],
{{1, 0}, 2} => [1, 2, 3, 4],
{{1, 0}, 4} => [1, 2, 3, 4]
}
The lists with non-consecutive numbers ([1, 3] and [0, 2, 4]) need to be split as each such list represents more than one side. After splitting we have the following lists:
[
[1, 2, 3, 4],
[1, 2, 3, 4],
[0, 1, 2, 3, 4],
[1],
[3],
[0],
[2],
[4],
[0, 1, 2, 3, 4],
[0, 1, 2, 3, 4],
[1, 2, 3, 4],
[1, 2, 3, 4]
]
There are now 12 sublists, where each sublist represents a side in the fence. By counting the number sublists, we get the number of sides.
2
jarlah
i think the chunk_while threw me off the bus maybe … other than that your explanation makes perfect sense when you say it like this
1
lud
jarlah
looked at it. I think i need to look more closely at it. But looks nicer. No wierd chunk while 
Unrelated segway:
i have been recently thinking about making an umbrella project in mix with a shared common project and sub projects for all years, and sub sub projects for all days .. then they are sort of standalone .. and if one day cant use the standard tooling or some depenency … i can just break it loose from the umbrella for that specific day
1
jarlah
ey .. what .. i can actually use normal function overloading in elixir ??
defp distinct_sides(cross_coords) do
[h | cross_coords] = Enum.sort(cross_coords)
distinct_sides(cross_coords, h, 0)
end
defp distinct_sides([h | t], prev, acc) when h == prev + 1 do
this got me spinning ! learned something new! yay no more new names for functions just because i need to do recursion. Makes sense though distinct_sides/1 and distinct_sides/3 ARE in fact different. Cognitive overhead though ..
but seriously i am actually understanding whats going on with your code.
1
lud
Yes despite the exact same name, because of the different arity, those functions in Elixir and Erlang are totally different functions that can have their own @spec, @doc, one could be exported while the other remains private, etc.
i have been recently thinking about making an umbrella project in mix with a shared common project and sub projects for all years, and sub sub projects for all days
You do you but honestly this looks like pain
I really like to be able to change some stuff in my shared modules and just call mix test to run all solutions for all years i’ve done without thinking about project structure.
2
cblavier
I struggled so much on the past few days that I’m proud this one went smoothly.
I confess that I read before coding anything that counting corners was a good strategy 
Part 1:
defmodule Advent.Y2024.Day12.Part1 do
defmodule Region do
defstruct [:plant, :area, :perimeter, :sides, plots: MapSet.new()]
end
def run(puzzle) do
puzzle
|> parse()
|> find_regions()
|> Enum.map(&compute_area_and_perimeter/1)
|> Enum.map(&(&1.area * &1.perimeter))
|> Enum.sum()
end
def parse(puzzle) do
for {row, y} <- puzzle |> String.split("\n") |> Enum.with_index(),
{plant, x} <- row |> String.graphemes() |> Enum.with_index(),
into: %{},
do: {{x, y}, plant}
end
def find_regions(farm) do
Enum.reduce(farm, {[], MapSet.new()}, fn {{x, y}, plant}, {regions, visited} ->
if MapSet.member?(visited, {x, y}) do
{regions, visited}
else
region = explore(farm, {x, y}, %Region{plant: plant})
{[region | regions], MapSet.union(visited, MapSet.new(region.plots))}
end
end)
|> elem(0)
end
def explore(farm, {x, y}, region = %Region{plant: plant, plots: plots}) do
region = %Region{region | plots: MapSet.put(plots, {x, y})}
for {nx, ny} <- [{x + 1, y}, {x - 1, y}, {x, y + 1}, {x, y - 1}], reduce: region do
region ->
if Map.get(farm, {nx, ny}) == plant and not MapSet.member?(plots, {nx, ny}) do
explore(farm, {nx, ny}, region)
else
region
end
end
end
defp compute_area_and_perimeter(region = %Region{plots: plots}) do
fences =
for {x, y} <- plots,
{nx, ny} <- [{x + 1, y}, {x - 1, y}, {x, y + 1}, {x, y - 1}],
not MapSet.member?(plots, {nx, ny}),
do: true
%Region{region | area: MapSet.size(plots), perimeter: length(fences)}
end
end
Part 2:
defmodule Advent.Y2024.Day12.Part2 do
alias Advent.Y2024.Day12.Part1
alias Advent.Y2024.Day12.Part1.Region
import MapSet, only: [member?: 2]
def run(puzzle) do
puzzle
|> Part1.parse()
|> Part1.find_regions()
|> Enum.map(&compute_area_and_sides/1)
|> Enum.map(&(&1.area * &1.sides))
|> Enum.sum()
end
defp compute_area_and_sides(region = %Region{plots: plots}) do
corners =
for {x, y} <- plots,
[{d1x, d1y}, {d2x, d2y}, {d3x, d3y}] <- [
[{-1, 0}, {-1, -1}, {0, -1}],
[{0, -1}, {1, -1}, {1, 0}],
[{1, 0}, {1, 1}, {0, 1}],
[{0, 1}, {-1, 1}, {-1, 0}]
],
[n1, n2, n3] = [{x + d1x, y + d1y}, {x + d2x, y + d2y}, {x + d3x, y + d3y}],
(not member?(plots, n1) and not member?(plots, n3)) or
(member?(plots, n1) and not member?(plots, n2) and member?(plots, n3)),
do: true
%Region{region | area: MapSet.size(plots), sides: length(corners)}
end
end
0
jarlah
made advancement to my setup
https://github.com/jarlah/advent_of_code
first i removed all input files and AOC descriptions and washed my git commit log.
then i moved every year into solutions directory and changed my mix task to generate actual mix projects that depend on a common mix project two levels above it
so now i have shared code in a common project with no umbrella and the parent project wont compile the code for the other projects since its not in the lib folder, it will only compile the mix task
1
ken-kost
Man I got stuck on this one. First I wasn’t able to parse correctly i.e. get the groups. Tried multiple approaches and although they would work on test examples it wouldn’t on the input. Day after I cracked it but then got stuck on part 2. So I was bashing my head yet again. Went here to maybe get an idea, and I did thanks to @bjorng
My code connects all adjacent pieces of the fence.
So that’s what I tried as well. I unpacked the fence calculation from part 1 to preserve sides information and then parsed that. Now I’m behind 3 days and it’s only getting harder. 
But I’ll persevere. 
defmodule Aoc2024.Solutions.Y24.Day12 do
alias AoC.Input
def parse(input, _part) do
[{first_line, 0} | rest] =
input
|> Input.stream!(trim: true)
|> Enum.with_index()
first_chunks =
first_line
|> String.codepoints()
|> Enum.with_index()
|> Enum.map(fn {e, y} -> {e, 0, y} end)
|> Enum.chunk_by(fn {e, _, _} -> e end)
Enum.reduce(rest, first_chunks, fn {line, x}, acc ->
line
|> String.codepoints()
|> Enum.with_index()
|> Enum.map(fn {e, y} -> {e, x, y} end)
|> Enum.chunk_by(fn {e, _, _} -> e end)
|> Enum.reduce(acc, fn chunk, groups ->
group_chunk(groups, chunk)
end)
end)
end
def part_one(problem) do
problem
|> Enum.reduce(0, fn group, acc ->
group = Enum.map(group, fn {_, x, y} -> {x, y} end)
fence =
Enum.reduce(group, 0, fn point, acc ->
acc + length(calculate_fence(point, group))
end)
acc + length(group) * fence
end)
end
def part_two(problem) do
problem
|> Enum.map(fn group ->
group = Enum.map(group, fn {_, x, y} -> {x, y} end)
Enum.reduce(group, [], fn point, acc ->
[{point, calculate_fence(point, group)} | acc]
end)
end)
|> Enum.map(fn group ->
h_chunks = Enum.chunk_by(group, fn {{x, _y}, _} -> x end)
counter_h = count_sides(h_chunks, :up, 1) + count_sides(h_chunks, :down, 1)
v_chunks = Enum.group_by(group, fn {{_x, y}, _} -> y end) |> Map.values()
counter_v = count_sides(v_chunks, :left, 0) + count_sides(v_chunks, :right, 0)
{length(group), counter_h + counter_v}
end)
|> Enum.reduce(0, fn {length, sides}, acc -> acc + length * sides end)
end
defp group_chunk(groups, chunk) do
case Enum.split_with(groups, fn group -> belongs_to?(group, chunk) end) do
{[], groups} -> [chunk | groups]
{chunk_groups, groups} -> [Enum.concat(chunk_groups ++ [chunk]) | groups]
end
end
defp belongs_to?(group, chunk) do
Enum.any?(group, fn {e, x, y} -> {e, x + 1, y} in chunk end)
end
defp calculate_fence({x, y}, list) do
result = []
result = if {x + 1, y} in list, do: result, else: [:down | result]
result = if {x - 1, y} in list, do: result, else: [:up | result]
result = if {x, y + 1} in list, do: result, else: [:right | result]
if {x, y - 1} in list, do: result, else: [:left | result]
end
defp count_sides(chunks, direction, index) do
Enum.reduce(chunks, 0, fn chunk, acc ->
acc +
case Enum.filter(chunk, fn {_point, fences} -> direction in fences end) do
[] ->
0
[chunk_up_head | chunk_up_rest] ->
{point, _} = chunk_up_head
e = elem(point, index)
{_, counter} =
Enum.reduce(chunk_up_rest, {e, 1}, fn {point, _}, {tracker, counter} ->
if elem(point, index) + 1 == tracker do
{tracker - 1, counter}
else
{elem(point, index), counter + 1}
end
end)
counter
end
end)
end
end
Also, I stumbled upon a behavior which was unexpected to me while working on this, regarding group_by/chunk_by.
I made a post here about it. 
1