14
this post was submitted on 02 Dec 2024
14 points (100.0% liked)
NotAwfulTech
385 readers
3 users here now
a community for posting cool tech news you don’t want to sneer at
non-awfulness of tech is not required or else we wouldn’t have any posts
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Day 7
1 and 2
On reflection, it was a pretty fun little problem to solve. There wasn't much of a difference between the two parts. I ran into some bugs with my recursion termination conditions, but I got them in the end.Part 1. A quick look at the data showed that the input length was short enough to perform an O(2^n^) search with some early exits. I coded it as a dfs.
Part 2. Adding concatenation just changes the base from 2 to 3, which, while strictly slower, wasn't much slower for this input.
code
Re: day 7 parts 1 and 2
same here, I was dicking around with combinatorics to get all combos of plus and multiply but realized before I got to the end it was gonna take too long. Then I figured that a DFS was the way to go.
I tried to optimize a bit by exiting early if the cumulative result became too large, but for some reason that gave me incorrect (too low) answers. Part 2 runs in around 1 min anyway.
https://github.com/gustafe/aoc2024/blob/main/d07-Bridge-Repair.pl
My graph search solves 7-1 and passes the example cases for 7-2, but gives too low a result for the complete puzzle input, and there's no way I'm manually going through every case to find the false negative. On to day 8 I guess.
7-2 Check case by simple graph search that mostly works
EDIT: total && index < (calibration.Length-1) -> false -- i.e. stop if you reach the total before using all numbers, well, also stops you from checking the next operator, So, removing it worked.
Rubber ducking innocent people on the internets works, who knew.
this looks like the same issue I had!
re: branch cutting
IDK if this is what your issue was, but one thing I ran into was that if you do something likeif (current_total >= target) prune(),
this can be problematic because if the tail end of the data is 0s and 1s, you exit too early. Basically I would prune strictly when the current total > target.re: branch cutting
thanks for the tip, I looked into it again and I found I was cutting in the wrong place. Fixed now, and halves the time for part 2
We love to see it