14
votes
Day 6: Wait For It
Today's problem description: https://adventofcode.com/2023/day/6
Please post your solutions in your own top-level comment. Here's a template you can copy-paste into your comment to format it nicely, with the code collapsed by default inside an expandable section with syntax highlighting (you can replace python
with any of the "short names" listed in this page of supported languages):
<details>
<summary>Part 1</summary>
```python
Your code here.
```
</details>
Well, that was a problem I guess
Part 1
Part 2
Surprise, same as part 1 but I changed info.jsonGlad today was easy. Today's language of the day is SQL, specifically PL/PGSQL. I never wrote a single function in SQL before, but I saw people use
WITH
and I thought it should be possible to solve AoC in one.By the way, this is my first solution this year that use a Regex - I did day 1-5 without a single regex.
Apparently SQL array starts from 1. That wasted me an hour.
For part 2 I'm too lazy to write a parser, so I just strip the number by hand. Takes 3s769ms to finish on my machine.
I'm a little surprised only one person seems to have even mentioned doing the math. I did Part 1 the code-heavy way to get some practice in with Counters, and I did Part 2 the math way because it would have just been copy+paste otherwise. I also parsed because I am learning so I'm trying to teach myself different things. I considered hard coding, but chose to do it the "hard" way. Although I'm now realizing that hard coding values would have let me use CONSTANTS instead of variables. How fun.
Part 1
Part 2
Suspiciously easy day, but I'm not complaining. Also I do like days where the input is short enough to enter manually into my source code while first solving. Anyway here are my Python solutions:
Part 1
Part 2
No change in computation for part two, only parsing the input:Are we in for something nasty tomorrow?
My solution in Common Lisp.
I almost had a sub-five-minute turnaround from part one to part two. But I implemented the closed form of the problem using
sqrt
and the single-float it was returning wasn't precise enough to get the right answer for part two. I spent a couple minutes double-checking the syntax to force it to return a double. (Solution: Pass it a double-float and it'll return one, too. To force its argument to a double, replace the4
in one part of the inner calculation with4d0
and let contagion do the rest.)That seemed ... super easy? After yesterday I was expecting something much harder. I finished both parts in 20 minutes and was still in the 4ks on the leaderboard.
I should have just copy-pasted the inputs into my code instead of messing around with parsing.
Spoiler comments
I suppose if you naively implemented the race as an actual simulation, instead of just computing the distance, maybe it would be harder? But even then, part 2 just scales linearly, so it was just ... change the input and rerun it?
Github link
Both Parts
yep that's what I did haha
I wasted time on parsing or I would've done better. Should've just copied the values straight into my code and I probably could've gotten a leaderboard spot. But oh well, can't win 'em all.
Solution
Google Sheets
with the inputs in A2:A3. For part 1 I split it out into H
Part 1
Part 2
Nthing comments that this really would've been faster if you just manually typed the inputs and the loop in a REPL.
Kotlin
Language: Python
Part 1
Not much to say... this was pretty straightforward.
Part 2
Probably could have done some math, but didn't need to :]
GitHub Repo
(Rust)
Parser
Parts 1 & 2
This took an embarassingly long time to write though. Off-by-one errors in a bisection search are nasty...
Performance
Huh. After yesterday's problem it didn't even occur to me that I could just brute force this, so I wrote a recursive bisection search. 478223210191071 seemed like a scary-large number to brute-force, but I guess computers are fast...
After all my issues with yesterdays code, today's was incredibly easy.
I made it more complicated than it needed to be as I was anticipating some more issues. Part 2 was definitely a bit slow from a performance issue, but I'm talking 5-10s slow, not minutes.
All my code
We have been blessed with an easy day. My code is a little more verbose than necessary, but I have some brain fog today so it was helpful to lay everything out more explicitly.
Part 1
I kinda cheesed part two by doing a little bit of dumb processing to keep my previous solution exactly the same, so here's what that looks like:
Part 2
Rust
Day 6
Originally 'brute forced' it (still only a couple thousand calculations even for part 2, under 20 ms in rust), but later remembered high school algebra, and basically the entire runtime of the solution is taken up by parsing the input.
https://git.venberg.xyz/Gabe/advent_of_code_2023/src/branch/main/days/day06
Elixir
Still playing catch-up, but this one was a nice break. I still did more work than necessary, though—I assumed part 2 would require optimization so I implemented a binary search with no guardrails (since it's guaranteed to find a value for each race in the puzzle input) and used math to compute the total number of winners from the first winning button-hold value. Yay for me, I guess?
Part 1 runs in ~12μs, part 2 in ~5.7μs. It takes longer to run multiple small searches than to run one big one! Thanks, O(log n)!.
Parts 1 and 2
Well, after day 5 this was refreshingly easy. Brute-force ran in ~4 ms even for part 2, but I wound up implementing a binary search that skips to linear searching when <10 elements are left anyway. With that, runtime for parts 1 and 2 combined comes out around 12 μs, making today the fastest day by roughly an order of magnitude.
Parser and data structure
Part 1
Part 2