aoc2015 VS aoc2018

When I solved this, I cheated .... and used the exact comment you linked to make my solution for part 2 really simple: it's just a direct calculation with the number of "parentheses" and "commas": https://github.com/ednl/aoc2015/blob/main/day19.py

That's a great simple way of doing gradient descent (ascent, in this case..). I added that to my explanation of the example, which was far too long and complicated: you don't need to limit the search space, just start in the middle! Obviously that's not something that will work in general, but the puzzle is well-behaved enough. They usually are.

Same with my version: https://github.com/ednl/aoc2015/blob/main/day05.py

You're correct! There are no time limits; in fact, you can work on any puzzle from any year, which means you can even start from the beginning of Advent of Code 2015 if you wanted to!

This is the seventh year puzzles, if you want to check out previous years take a look at: 2015, 2016, 2017, 2018, 2019, 2020

Throughout the spring and summer of 2021 a few of the times that I mentioned on the Advent of Code subreddit that I was doing the 2015 problem set in all 3 languages, some folks said they’d be interested in a writeup on the experience. Now that I’ve finally finished 2015 (my first set of 50 stars!) it’s time for that writeup. Before I continue, I’d like to thank everyone on the subreddit who has helped me. I have a README.md for each day’s problem and you’ll find my thanks to those who helped me within those READMEs here in my repo.

Here's an example where switching to int8/int16 sped up my program 3x, but insignificantly compared to development and compile times, namely from 15 to 5 ms. I haven't profiled it but I suspect it's because of the reduced memmove amounts in my improvised bsearch-sorted-array-insertion. Made this yesterday, solution to Advent of Code 2018 day 20: https://github.com/ednl/aoc2018/blob/main/20.c

I made this jupyter notebook for a better idea and to directly compare different grid serial numbers. I think the condition "stop when no new max has been found twice in a row" will work most of the time. I tested a few other serial numbers and it seemed OK: the condition is only true directly AFTER the absolute maximum. But yes, there could well be other serial numbers where there is a dip of length 2 BEFORE the absolute maximum. Screenshot of the graph from the notebook: https://i.imgur.com/VXXpZnh.png

This is the seventh year puzzles, if you want to check out previous years take a look at: 2015, 2016, 2017, 2018, 2019, 2020

Well, I think I mostly got it. But what I couldn't figure out was which updates to skip, so maybe it can get a bit faster still. Time on the M1 Mac Mini was 4.3 ms for combined user+system, see below. That system time being as long as the user time is maybe from the massive heap allocation and init to zero at program start? I also tried to do it dynamically with malloc, without block initialisation, but that was a tiny bit slower, so I left it as a static array. Pi 400: 98 ms, old Macbook from 2013: 36 ms (both same deal: user time = system time). Code: https://github.com/ednl/aoc2018/blob/main/day09alt.c

This is my solution in C which runs in under 2 ms: https://github.com/ednl/aoc2018/blob/main/day16.c