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

Pythonsolutions:## 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

almosthad 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 the`4`

in one part of the inner calculation with`4d0`

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

## part 1

## part 2

## performance

I was prepared for a similar situation as yesterday where the brute-force option would take an infeasible amount of time and I'd have to optimize it, but it turned out to be fast enough that I said fuck it.

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

ElixirStill 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