Advent of Code - adventofcode.com

Lagrange interpolation eh? That would have been nice to know 24 hrs ago. Fortunately it was bruteforcable.

Day 8 was a killer too. Someone mentioned the Chinese remainder theorem (which I'd also never heard of, but fortunately wasn't actually necessary)

I haven't completed an AoC before - does the complexity keep increasing or does it tend to plateau?

It varies. Weekends tend to have trickier ones. I tend to run out of steam about halfway through although if I make it to day 5 this year I'll be doing well I think.
Check out previous years - they're all in the site

Check out previous years - they're all in the site

sounds too much like hard work

There's a good visualisation of previous years completion times for the top 100 (which is a reasonable proxy to complexity) here by fixie skidder Prof jwo: https://github.com/jwoLondon/adventOfCode#completion-times

Yes it definitely gets harder. The time for the 100th completion of some of the days gets into multiple hours (the 100th person to finish part2 today [day 10] took ~36m for example).

Just done Day 10 part 1 on the bus on the way to watch my daughter play football, running out of time to get part 2 done, and then I'm off to watch Fulham this afternoon so it's going to have to wait until later this evening. Think I know how to do part 2 quite easily but having it rattle around in my brain for a few hours will be a good thing.

Just back from footy, took ~10 mins (including fixing one annoying bug) to do part2 having had so long to think about it...

I'm still on day 5. Got busy and fell behind a bit.

Depends how the difficult ones fall and the weekends but I tend to fall behind around Day 22 or so when I stop work and end up doing loads of family things instead.

I try and get it all finished on the 25th though, so it means I have to be caught up by the end of the 24th to have any hope of that. Otherwise it gets ticked off before the end of the year.

All done up to and including Day 11 and runtime is a whole 0.034s so far.

And Day 12 brings one that is a bit tastier...

🌶️🌶️🌶️🌶️🌶️

Got Day 12 down to 49ms. That'll do for now but there's definitely more that can be done.

Those are rookie numbers. My solution has been running for 5hrs and it's less than halfway through

Seeing a bit more attrition than I'd expect on the various private leaderboards I'm on.

Expecting a couple of bastard days in the next few days too.

Pretty cruisy one today

Yeah, it's going to be a bit of work to make it faster though.

I fear for tomorrow though. I'm out tonight so I'll be very hungover and I've also got another party to go to in the afternoon.

Got my parser for day 2 written at least
https://github.com/rhowe/aoc/blob/main/2023/02/part1.S

Day 17: not as spicy as day 12, but still 🌶️🌶️🌶️

Caught up after being out all day.

Day 17: Took me way too long to realise that you could start by going right OR DOWN.

Runs in about 1.5s so work required to fix that, but ICBA right now.

Did some optimisations.

Total time for 2023 so far (up to and including day 18): 0.378s

That's impressive. You're doing it all in Go, aren't you?

Yay, day 2 part 1 done: https://github.com/rhowe/aoc/blob/main/2023/02/part1.S

Need to implement actual multiplication for part 2 :(

Yep. Trying to expand my experience with Go as that is what I write in professionally nowadays.

Used container/heap for the first time on Day 17 to provide a priority queue to make implementing Dijkstra easier/faster. I normally just cobble together my own priority queue but thought this was a good time to learn how to do it properly.

Nominal target of the whole year in under 1s so I try and get each day down to under 4ms, but I'm guessing there are some days that are going to take real effort to optimise that much, and it may just be impossible for some problems. I'm slowly going back and doing all of the previous years in Go too, but that's a slightly longer project. Still have ~90 days to sort out, and I need to revisit a bunch given what I've learned over the last 2 years.

[EDIT] AoC means different things to different people, there's no right or wrong way to do things.

My approach is relatively simple. I have 3 goals (with one bonus if I can be arsed):

• Goal 1: Make it work = just get the answer
  
• Goal 2: Make it correct = ensure the edge cases are covered, make sure it should work on any input (e.g. there's no hardcoded assumptions in there)
  
• Goal 3: Make it fast = understand the different approaches and find the most appropriate algorithm, but don't sacrifice understandability for tiny increments in speed
  
• Bonus Goal: Make it neat and tidy = really prettify it, add tests, etc
  

What are you doing it in?

I'm using Ruby.

People often use AoC to learn a new language, but I'm trying to do well on a couple of the leaderboards I'm on, so I had to stick to what I know best.

I think it's a pretty good language to go fast in AoC with. It's bristling with features, and it's text munging abilities are excellent.

In these later levels though, there comes a point where you can't just brute force part 2 with your solution to part 1, and that point comes earlier for Ruby.

I live in Australia btw, so challenges come out at 4pm, which is very convenient for me. I'm not up at 5am every day.

Yeah, I'm far faster to getting an answer in perl than I am in Go, but doing it in Go once I've already got a solution in perl is way easier than doing it in Go from the beginning.

perl is way faster for string munging, type casting, etc.

I'm not worried about leaderboards (since they're mostly just proxies for timezones and how busy they are at work) so I tend to do it in Go from the start just to make me think in a Go way.