Revenge, blast from the past etc!
Had to learn Dijkstra's for this one. Was as stuck
as one can be on AOC. This stopped my progress
2023, and kept me busy at least 20-30h this year
(2024) as well. I never came past part 1, but got
part 2 in minutes when I hit home.
Turns out the initial queue was to blame, after
studying Dijkstras, reading hints on the subreddit
and tutorials in blogs. I was off-by-1 in costs,
since I misplaced a read from the grid.
I also struggled a really, really long time with
a bug where I resetted the steps to aggresively.
What helped me to figure it out was to create
simpler test case grids and step-debug them.
Example 1:
241
321
should give a least heat loss of 6 in pt1.
Example 2:
11199
12199
99199
99131
99111
should give a least heat loss of 9 in pt2.
WALLOFTEXT for part 2, took me 90 minutes to find
this important text:
> Each step begins with a sequence of letters that
> indicate the label of the lens on which the step
> operates. The result of running the HASH algorithm
> on the label indicates the correct box for that
> step.
It also clarifies how part 2 and part 1 relates.
Got completely stuck on part 2. Tried some polygon
area calculations, but none provided the correct
answer, most likely due to the unorthodox polygon
points.
I also tried _shoelace method_ without any luck.
Had not heard about that one earlier, it was a good
learning experience even though I vould not use it
here.
By the subreddit, several people had had luck
using the ray method.
> Part 2 using one of my favorite facts from
> graphics engineering: lets say you have an
> enclosed shape, and you want to color every
> pixel inside of it. How do you know if a given
> pixel is inside the shape or not? Well, it
> turns out: if you shoot a ray in any direction
> from the pixel and it crosses the boundary an
> _odd number_ of times, it's _inside_. if it crosses
> an even number of times, it's outside. Works
> for all enclosed shapes, even self-intersecting
> and non-convex ones.
Increasing speed from 66mins to 4mins. Caching the
location value in the code to keep things at highest
speed.
From the subreddit, the algorithm looks like this.
1. Start att location 0
2. Traverse the whole process backwards, by
reversing process steps and flipping dest/src
positions.
3. Output is not a location, instead it's a seed.
4. if seed is in any seed range, use seed to get
location as in step 1.
5. If not, increase location by 1 and repeat 2-4.
Part 2 would have taken 10-15 hours with brute force.
After I figured out the puzzle input had circular
A-Z paths, it was plain as day that LCM was the
solution to the problem.
https://en.wikipedia.org/wiki/Least_common_multiple
On a train that according to swedish tradition
was late. Not a good environment to focus.
Got stuck 2 times:
- Initial code asumed the | was always after the 5th
number, because of the example. Puzzle input had
it at pos 10. Classic AoC mistake.
- I had a hard time trying to understand the score
count, I insisted there was meant to be a +1 at
some point.
> That means card 1 is worth 8 points (1 for
> the first match, then doubled three times for
> each of the three matches after the first)
I should instead have just looked at the numbers.
Turns out re methods are non-overlapping. And in
true AoC manners, no provided test cases had
overlaps.
Luckily for me, some of the last lines in the input
contained the string "oneight", so I was able to
find it out quite fast.
Revisions:
1) Reverse strings to find last digit
2) Use isdigit() and skip regex.
3) Use regexp with positive look-ahead.
Turns out the initial trial of using
Manhattan distance was required to
solve part 2, since the BFS
implementation is impossible to
scale up from 2 robots to 25.
Recursion and memoization makes the
execution time acceptable.
Line 53 makes all the difference here.
The order of `<|v|^|>` matters when
constructing a sequence. Many
hours was spent trying to find the correct
priority. For the example input, especially
456A and 379A were volatile.
Part 1 was relatively easy, 2 was harder.
> So, by asking the monkey to sell the *first time*
> each buyer's prices go down 2, then up 1, then
> down 1, then up 3, you would get 23 (7 + 7 + 9)
> bananas!
Emphazis mine. Earlier versions of the code missed
this fact, and added all occourences of the sequence.
providing a answer that is too high.
BFS to get the path from start to end.
pt 1 took some time to wrap around, and initial
versions of the code used defaultdict() to keep
counts of all cheats to check if the example
puzzle input gace the right counts for the cheats.
But since only 100 or more was requested, a counter
do the job in the final version of the code.
For pt 2, a permutation is used.
Slow burner.
First part was a straightforward implementation
of a runner, the code is extracted to `org_version()`.
Part 2 was way more tricky. Like many others, trying
to understand the program felt necessary. This
intepretation is this:
"""Python version of puzzle input program."""
a = <unknown>
b, c = 0, 0
while a:
b = (a % 8) ^ 1
c = a // (2**b)
b = (b ^ 5) ^ c
a = a // (2**3)
print(b % 8)
Some clarification here:
- the value is octagonal. 1-8 is the key.
- The value of reg a is _high_. It is not meant to
be brute forced.
The idea, which is not originally mine, is to go
from right to left. This code can be used to try
out some patterns:
while True:
python_version(input("Provide A:"))
Here, it was apparent a=4 gives the last digit of
my puzzle input. a=37 (4 * 8 + 3) gives the last
2 digits. a=222 (37 * 8 + 6) gives the last 3
digits, and so on.
Knowing the program could be reconstructed like
this, the first code halted at wrong values. Turns
out some steps give more than 1 possible scenario.
The code was therefore in need of a queue.
Initial tries to use a while loop instead of
recursion gave a classic AoC situation: test cases
worked, but not actual AoC puzzle input.
Turns out I only considererd removing the longest
pattern form the design, rather than consider all
possible removals.
Some Python goodies in here:
- `"abcdefgh".startswith("abc")` instead of regexp.
- removeprefix() is nice, and in some cases more
readable. `"abcdefgh".removeprefix("abc")` vs
`"abcdefgh[3:]"
- To speed things up for pt 2, functools is used
which requires a dict to be hashed as a tuple.
If one wish to solve this without recursion, a
BFS solution is most likely the way to go.
def ispossible(design, patterns):
Q = [design]
possible = 0
while Q:
remaining = Q.pop(0)
if not remaining:
possible += 1
continue
for pattern in patterns[remaining[0]]:
if remaining.startswith(pattern):
Q.append(remaining.removeprefix(pattern))
return possible
Part 1 was easily solved by Dijkstras (using heapq).
Tricky part was to find the way to serialize the
queue items for the heappush and heappop to behave
as required.
Part 2 was incredible hard to figure out, and I
could not do it by myself. From the subreddit, it
is hinted that a traditional set of visited nodes
to determine algorithm exit would not work.
After some laboration and readin some hints, I
managed to find a solution where the code keeps
tracks using a defaultdict.
After working overtime to solve day 12, this brief
task was a much welcome change.
For pt 1, the code uses integer division and
modulus to update all positions. The tricky part
was to determine which quadrant got the middle
column and row (since dimensions was odd numbers,
and either left or right quandrants is +1 longer),
which was straightforward to verify by the test
cases.
For pt 2, the remains of the code used to visually
identify the tree is left under the `find_easter_egg`
toggle.
Basically, the code prints the grid with
all robots marked as a `#`, and free space as `.`.`
This wording of the puzzle is important:
> very rarely, _most of the robots_ should arrange
> themselves into a picture of a Christmas tree.
"most of the robots" means the tree will be quite
visible, which also means it is safe to asume a
significant cluster of "#" would appear over time.
By keeping track of the counter (seconds the robots
has traveled), it was evident that the cluster of `#`
occoured th first time at i=64 and every 103th
time forward.
In other words, `i % 103 == 64` will most likely
give a tree. The print statement is therefore
limited to those i's, and at `i == easter_egg_appearance`
the tree is visible.
So, to be extra clear: 64, 103 and pt2 answer is
unique to my puzzle input. If this code is used
with any other puzzle input, these numbers will
most likely vary.
For the fun, the code also contains the `display_easter_egg`
flag to actually print the tree. This is provided
to indicate how big the actual tree is: 33*36 chars.
Also, the `sints` utility function was added to
extract all signed ints from a string.
Funny that original 2023 day 5 also was a PITA
to figure out.
Pt 1 was solved using BFS to flood-fill. After
trying some different methods for pt 2, including:
- wallcrawling,
- side couting,
- corner counting
I never produced code to get past the test cases.
- Wall crawling are hard due to overlapping
regions.
- corner couting and side counting are both hard,
but will act as equally good solutions (since side
count equals corner count).
- Concave corners are hard, convex corners are
easy.
The final code is based on the posts on the
solutions megathread. Changes:
- Keep all areas in a set, defining a region.
- find all convex and concave corners in each
region.
A new helper got introduced: Di, storing all
diagonal neighbors for grid traversing.
Convex corners:
.. R. .R ..
R. .. .. .R
Concave corners:
RR .R R. RR
.R RR RR R.
Initial version of the code tried to solve pt 1
using BFS, which took way too long even for the
test data.
After some fiddling with algebra with pen and paper,
I realized this 2 formulaes (using first example):
94 * b1 + 22 * b2 == 840
34 * b1 + 67 * b2 == 540
*b1 = button A presses
*b2 = button B presses
... could be rewritten to this single expression:
(94 + 34) * b1 + (22 + 67) * b2 = 840 * 540
I failed to remember the algebra for solving x than
y though, that I had to learn from the subreddit.
In the code, this is the ratio part.
Also, this solution using fractions is SICK.
https://www.reddit.com/r/adventofcode/comments/1hd4wda/comment/m1tz3nf/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
Loooong time overdue. First drafts of the code
kept track of every id separately in a defaultdict.
This was not sustainable since the code examples
had some recurring ids, and after managing to
support the test cases the code was eay off for
the real puzzle input.
In the end, the whole code was deleted and replaced
by a BFS solution that expands the current regions
until it finds no more areas.
Got the trick to count all perimiters in an else clause
from a leaderboard placed youtuber.
First part was solved using a list to store stones,
since I misinterpreted this paragraph:
> No matter how the stones change, their order is
> preserved, and they stay on their perfectly
> straight line.
But since the puzzle question do not require the
stones in the correct order, a list (or an OrderedDict)
is not required.
The pt 1 solution code got killed for eating all
RAM, so valuable minutes was lost trying to create
a generator instead. It failed. When searching for
clues, I ran across multiple people instead
utilizing dicts to count occourences. "but what of
the order?", I asked, and realized only the counts
was relevant.
Hard one. Comparing to earlier years, the
difficulty level seems higher than usual. I blame
the LLM hipsters.
This one I asumed, but missed when I tried to
find it:
> "If a block contains free space, skip it instead."
Lucky me.
As many have said, the puzzle text this day
was a bit challenging to parse and understand.
Especially this part of pt 2 was easy to miss:
> In fact, the three T-frequency *antennas* are all
> exactly in line with two antennas,
> so *they are all also antinodes*!
not including the antennas in pt 2 gave an slightly
too low answer.
Got thrown of big time at pt 1 since there is a
duplicate test value in my puzzle input. The code
initially asumed that all test values should be
distinct. Biased from seeing "test" in the
termology, most likely.
Earlier editions of the code also tried to create
all combinations using binary strings, but it fell
short on pt 2 when a third operation was introduced.
From some inspiration in the solutions mega
thread on Reddit, the final code is queue-based
instead. Apparently, I also learned this kind of
problem is usually well suited for DFS search, and
apparently the final code very much is _in deed_
a DFS.
Pt 1 was easy, Pt 2 was pure horror.
Earlier drafts of the code tried to be way too
smart. At one point, I just came to the conclusion
to place a new obstacle (#) on the grid and just
rerun the thing to look for loops.
2 things:
- the visited positions from pt 1 can be used as a
subset for positions to consider for the extra
"#".
- The track of loops can be optimized to look at
bounces on "#"s instead of each individual y,x pos,
given that the direction is remembered.
pt 2 is familiar, the last time a puzzle required
look detection the puzzle used lazer beams and
reflectors. Not sure what Event or day it was.
In p2, it took some tries to find a correct way
to rearrange incorrect pagesets. The code ended
up just rearranging first found incorrect order
and readding the updated pageset to queue.
