Update README.md

Author: carnundotcom

README.md

@@ -37,8 +37,9 @@
 | 2023 | [4](src/y2023/d4.clj) | neat! |
 | | | |
 | 2024 | [1](src/y2024/d1.clj) | I think I'll break from, uh, _tradition_ this year and write marginally more serious summaries! :D</br></br>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](https://clojure.org) beginners), _performant_ solutions. In roughly that order.</br></br>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](https://clojure.org) 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")`</br></br>P.S. Do also check out the [#adventofcode](https://clojurians.slack.com/archives/C0GLTDB2T) channel in Clojurians Slack! There will be daily solution threads. I always learn a lot from them. |
-| 2024 | [2](src/y2024/d2.clj) | 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](https://clojuredocs.org/clojure.core/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.</br></br>I had worried about this resulting in needlessly, repeatedly scoring the same pairs, so I [memoize](https://clojuredocs.org/clojure.core/memoize)d 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 | [2](src/y2024/d2.clj) | 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`](https://clojuredocs.org/clojure.core/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.</br></br>I had worried about this resulting in needlessly, repeatedly scoring the same pairs, so I [`memoize`](https://clojuredocs.org/clojure.core/memoize)d 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](src/y2024/d3.clj) | Cute! A nice short one this morning. It will be interesting to see if subsequent days expand on it... :D |
-| 2024 | [4](src/y2024/d4.clj) | Enjoyed this one! I was glad to be reminded that [clojure.core.matrix](https://github.com/mikera/core.matrix) exists, after first spending a few minutes fiddling with a rather imperative loop to generate the *diagonals* for **Part One**. `m/diagonal` did just what I wanted.</br></br>As for **Part Two**, I didn't immediately see a way to re-use my initial (regex over string lines) approach... so I didn't bother. Instead I generated a list of all the three-by-three sub-matrices and simply matched characters.|
+| 2024 | [4](src/y2024/d4.clj) | Enjoyed this one! I was glad to be reminded that [`clojure.core.matrix`](https://github.com/mikera/core.matrix) exists, after first spending a few minutes fiddling with a rather imperative loop to generate the *diagonals* for **Part One**. `m/diagonal` did just what I wanted.</br></br>As for **Part Two**, I didn't immediately see a way to re-use my initial (regex over string lines) approach... so I didn't bother. Instead I generated a list of all the three-by-three sub-matrices and simply matched characters.|
+| 2024 | [5](src/y2024/d5.clj) | Proud of myself today. Started down the road towards *brute forcing*... but stopped before I got too far, and found a neat trick instead! :)</br></br>In short, consider: (1) each 'update' implies its own set of rules; and (2) if one or more of these rules is *backwards* with regards to the actual rule set, the 'update' is out-of-order.</br></br>That's it!</br></br>As for **Part 2**, the rule set trivially entails a [comparator](https://clojure.org/guides/comparators) that can be passed to [`sort-by`](https://clojuredocs.org/clojure.core/sort-by). Fun!|
 
 Feedback welcome!