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.
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.
DDOS of adventofcode.com, did not get to open the
puzzle until 06:05 (five minutes local time).
Screwed up the zip() and lost valuable minutes by
trying to replace it with itertools, only to find
I have made a typo (did AB CD EF instead of AB BC
CD).
I also lost valuable minutes by tring to solve p1
with one nested loop. Stupid.
For part 2, I created the issafe() helper to be
able to remove items from reports and test, one
at the time.
Realized afterwards I got the ints() helper, so
original code before cleanup splitted the input and
mapped all words with int(). valuable seconds lost
there.
Also, collections.Counter() was used initially since
I was too tired to remember count() method in lists.
Line 8 took the longest time to figure out. A typo
took 1-3 minutes to find for part 2.
Form: Sleep deprived, felt slow.
