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.
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.
Felt paranoid on this one, was expecting something
much worse for pt2.
The code that solved the puzzle was _extremely_
naive:
- It asumes puzzle input only contains mul() with
1-3 chars. The versioned code have `{1,3}` as safe
guard.
- p2 asumed initial chunk does not begin with
"n't". Would have been easy to handle though.
- p2 asumed junk strings as "don", "do", "don()t"
would not exist.
In other words, I was really lucky since I did not
look that closely on puzzle input beforehand.
Might have cut 60-90 seconds further if I had just
ran pt2 immidately instead of staring dumbly on the
test data (that changed for pt2).
Also, I got reminded that \d in regular expressions
is equal to `0-9`: it does not include commas and
punctations. The code that solved the puzzle was
paranoid and instead used `0-9`.
Managed to score ~1500th somehow despite this.
