| year | day | summary |
|---|---|---|
| 2015 | 1 | reduuuuuuuce |
| 2015 | 2 | simple regex, yummy destructuring, map/reduce... fun! |
| 2015 | 3 | reduce is very versatile! |
| 2015 | 4 | clojure is plenty fast, eh? |
| 2015 | 5 | maybe helper functions would be more readable? otherwise, simple enough :) |
| 2015 | 6 | had some (but not tooooo much) fun optimising, ha |
| 2015 | 7 | WIP |
| 2020 | 1 | (just warming up for 2024!) |
| 2021 | 1 | off to a nice, neat start |
| 2021 | 2 | sooo much nicer than my first attempt! |
| 2021 | 3 | not terrible |
| 2022 | 1 | let's goooooo! |
| 2022 | 2 | alright: I was a bit distracted :P |
| 2022 | 3 | neat... but feels like the calm before the storm |
| 2022 | 4 | ditto |
| 2022 | 5 | parsing is a little inelegant, but the rest was fine :) |
| 2022 | 6 | piece of piss |
| 2022 | 7 | SO IT BEGINS |
| 2022 | 8 | eh... quite ugly :/ |
| 2022 | 9 | not too bad! |
| 2022 | 10 | neat enough! |
| 2022 | 11 | part 1? fine. part 2? uhhhhh... |
| 2022 | 12 | a little ugly. but more importantly: slowwwww... |
| 2022 | 13 | little hard to understand the spec, but got there in the end |
| 2022 | 14 | easy enough; wordy solution though |
| 2023 | 1 | overlapping regex, grrrrr... |
| 2023 | 2 | zero snags; enjoyed making it nice :) |
| 2023 | 3 | easy peeeeez... once I figured how best to parse things |
| 2023 | 4 | neat! |
| 2024 | 1 | I think I'll break from, uh, tradition this year and write marginally more serious summaries! :D That said, not much to say about this one. Nice warmup. Hopefully I can keep up the readability, among other things, as we go on — because if I had a goal for AoC 2024 it'd be to produce elegant, readily understandable (especially to Clojure beginners), performant solutions. In roughly that order. I know I'm going to miss some days. But at the very least I hope to keep up, then swing back later to fill in any gaps. There's only so much time in December for 'toy problems' anyhow... which as it happens is a happy constraint. I'm very grateful that Clojure isn't just a toy language for me, but a living. Perhaps my rushed solutions here can help others into the same predicament? (repeat "ONE OF US")P.S. Do also check out the #adventofcode channel in Clojurians Slack! There will be daily solution threads. I always learn a lot from them. |
| 2024 | 2 | This one was fun! My initial approach to Part One — based on partitioning each 'report' into pairs, then checking the first pair to determine whether the rest of the report should increase, decrease, or had already failed — didn't seamlessly scale to Part Two, so I had to go back to the drawing board a bit. What I ended up with was one big reduce that first scores each report based on number of increasing pairs, number of decreasing pairs, and number of 'bounded' pairs; checks whether a score is 'safe' (i.e. the bounded total, plus either the increasing or decreasing total, equals the number of pairs); then if it isn't (and a retry? arg is true), runs (lazily) over the possible alternate reports missing one element until either a safe alternate is found, or there are no more alternates to test.I had worried about this resulting in needlessly, repeatedly scoring the same pairs, so I memoized the score-pair function. But this didn't seem to make any measurable difference to performance — plenty fast in either case. Perhaps with much larger 'reports', or a 'tolerance' higher than one bad element, things would get more interesting. :) |
| 2024 | 3 | Cute! A nice short one this morning. It will be interesting to see if subsequent days expand on it... :D |
Feedback welcome!