Day 17 documentation

Author: abyala

docs/day17.md

@@ -1,154 +1,144 @@
-# Day Sixteen: Ticket Translation
+# Day Seventeen: Conway Cubes
 
-* [Problem statement](https://adventofcode.com/2020/day/16)
-* [Solution code](https://github.com/abyala/advent-2020-clojure/blob/master/src/advent_2020_clojure/day16.clj)
+* [Problem statement](https://adventofcode.com/2020/day/17)
+* [Solution code](https://github.com/abyala/advent-2020-clojure/blob/master/src/advent_2020_clojure/day17.clj)
 
 ---
 
-Today's problem was a matter of parsing a complex incoming string, and then doing a bunch of set manipulation, maps,
-and filters. To be honest, I didn't find this one very entertaining, so I'm just going to quickly run through what
-each function does, show how the shape of the data changes from function to function, and call it a day.
+This problem reminds me of day 11, where we're given a set of points within a space, and we perform a
+generational calculation on it some number of times.  As I've done a few times, I'm going to cheat a
+little bit by having seen what part 2 looks like, but honestly the level of effort to go from part 1
+to part 2 was very small this time, so I feel comfortable showing them both at once.
 
----
-
-## Part 1
+We are given as input a 2-dimensional grid of points, where the ones marked with `#` signs are considered
+"active." For every point in infinite directions, we define that point to be active if it was active in
+the last generation and it has 2-3 active neighbors, or if it was inactive and has exactly 3 active
+neighbors. In part 1, an "active neighbor" looks at the 26 points up to one distance away in the
+3-dimensional `[x y z]` space. In part 2, an "active neighbor" looks at the 80 points up to one distance
+away in the 4-dimensional `[x y z w]` space. Everything else is the same, so we know how parts 1 and 2
+will differ!
 
-The `parse-input` function parses the incoming String into my state object. I leverage the `utils/split-blank-line-seq`
-function from a few problems ago, which converts the giant String into three components -- one for the rules, the
-"your ticket" section, and the "nearby tickets" section. Then it's a little regex and a whole lot of Integer parsing.
-The output shape is a map, that definitely could be simplified if I were so inclined.
- 
-```clojure
-; Output shape
-{:fields [["name" [low1 high1] [low2 high2]]]
- :my-ticket [1 2 3 4]
- :nearby-tickets [[1 2 3] [4 5 6] [7 8 9]]}
-```
+## Parts 1 and 2
 
-The `invalid-fields` function looks at all of the fields and combines them into a single list of `[low high]` pairs.
-Then the `flatten` function fully flattens the nearby tickets into a single list of integer values, which we filter
-down using `not-any?` to return only the values that aren't within any of the ranges. The output shape is a simple
-list of integers, representing the invalid fields.
+As always, let's think about the shape of the data we want, so we can decide how to parse the input. One
+option is to think of nested vectors, so a vector of vectors of vectors for part 1, and the very exciting
+vector of vectors of vectors of vectors for part 2. My brain doesn't like that sort of thinking, so I went
+another way. The neighbor calculation is going to look only at the number of active neighbors, so I'll
+parse the input into a set of `[x y z w]` points, and work with a simple set.  Since the input data is
+defined to be two-dimensional, my `z` and `w` coordinates all start at zero.
 
 ```clojure
-(defn invalid-fields [{:keys [fields nearby-tickets]}]
-  (let [every-range (->> (map rest fields) (apply concat))]
-    (->> (flatten nearby-tickets)
-         (filter (fn [fld] (not-any? (fn [[x y]] (<= x fld y)) every-range))))))
+(defn parse-input [input]
+  (->> (str/split-lines input)
+       (map-indexed (fn [y row] (map-indexed (fn [x c] [[x y 0 0] c])
+                                             row)))
+       (apply concat)
+       (keep (fn [[coords v]] (when (= v \#) coords)))
+       (into #{})))
 ```
 
-Then `part1` just adds together all invalid fields.
+_Quick note:_ I recognized something that I did not leverage in my solution. Because we started from 
+active nodes all in a 2-dimensional space where `z=0`, it stands to reason that there is going to be
+symmetry. Whatever exists at `z=-1` should also exist at `z=1`. I suppose I could leverage this by
+only calculating positive `z` values and then doubling the results for the negative `z`s, but I didn't
+do that. The same is probably true for the `w` axis. Meh; the performance was fine without it.
+
+The most important part of this problem is calculating all of the neighbors of a given point. Rather
+than use 3D points for part one and 4D points for part 2, after reading the part2 instructions, I
+treated all points as 4D.  My `neighbors-of` function looks at all points whose `x`, `y`, and `z` values
+are offset by a value in `[-1 0 1]`; the `w` axis will also be off by one of those values if we look in
+4D, but will always have an offset of `0` if we're only in 3D. As a result, I made two helper `def`s
+to show how we think about the problem set.
 
 ```clojure
-(defn part1 [input]
-  (->> input parse-input invalid-fields (apply +)))
+(defn neighbors-of [four-d? [x y z w]]
+  (for [new-w (if four-d? [-1 0 1] [0])
+        new-x [-1 0 1]
+        new-y [-1 0 1]
+        new-z [-1 0 1]
+        :when (some #(not= 0 %) [new-x new-y new-z new-w])]
+    [(+ x new-x) (+ y new-y) (+ z new-z) (+ w new-w)]))
+(def neighbors-3d (partial neighbors-of false))
+(def neighbors-4d (partial neighbors-of true))
 ```
 
----
-
-## Part 2
-
-Part 2 was a little trickier to solve, and my answer is a bit wordy. But I wanted to focus a bit more on transforming
-the data from one state to another, rather than doing everything inline as a giant list. So the solution is a bunch
-of small transformations.
-
-The overall strategy was to rip apart the complexity of the ticket structure. So I wanted to make a map of sets. To
-start, every ticket field was mapped to the set of all possible field indices. Then we go through every nearby ticket,
-and for every field type in which the ticket field doesn't fit, remove that index from the field type's set of 
-indices. By removing every rule violation, we should be left with only the field types and the indexes for which all
-tickets validate. So with that... 
-
-`valid-tickets-only` takes in the full state, and returns only the nearby tickets that are valid, meaning that they
-don't have any of the fields described previously in the `invalid-fields` function. This returns all of the remaining
-tickets in their normal form, so `[[1 2 3] [4 5 6] [7 8 9]]`.
+Next, I defined `bounding-cube` to identify the range of `x`, `y`, `z`, and `w` coordinates that we
+need to look at, given the previous generation. Because a point only considers the number of active
+neighbors, we can find the min and max values in each dimension, and look at the points one below
+the min and one above the max. This function returns a four-element vector of tuple vectors, representing
+the min and max values we need to scan in the `x`, `y`, `z`, and `w` dimensions.
 
 ```clojure
-(defn valid-tickets-only [{:keys [nearby-tickets] :as parsed}]
-  (let [bad-fields (-> parsed invalid-fields set)]
-    (filterv (fn [t] (not-any? #(bad-fields %) t))
-             nearby-tickets)))
-```
-
-The next function, `ticket-pairs`, rips out every `[idx v]` tuple across all of the nearby tickets, since I found that
-easier to reason with than keeping the original vector of vectors. So this function takes in the ticket list, of shape
-`[[1 2 3] [4 5 6] [7 8 9]]` and returns a simple `[[0 1] [1 2] [2 3] [0 4] [1 5] [2 6] [0 7] [1 8] [2 9]]` vector.
+(defn bounding-cube [active-points]
+  (mapv (fn [offset]
+          (let [values (map #(get % offset) active-points)]
+            [(dec (apply min values)) (inc (apply max values))]))
+        [0 1 2 3]))
+``` 
+
+With these ranges ready, let's identify all of the points in the bounding cube that we'll need to
+inspect on each generation.  This is simply the Cartesian product of all points within the above
+ranges. Now the ranges out of `bounding-cube` are inclusive, but the `range` function is open on
+the start and closed on the end. Rather than make a top-level function, I use the seldom-used
+`letfn` function, to define a locally scoped function `inclusive-range`, which returns a range
+that's inclusive of both the start and end values.
 
 ```clojure
-(defn ticket-pairs [tickets]
-  (mapcat (fn [ticket] (map-indexed (fn [idx v] (vector idx v)) ticket))
-          tickets))
+(defn points-in-cube [[cube-x cube-y cube-z cube-w]]
+  (letfn [(inclusive-range [[low high]] (range low (inc high)))]
+    (for [x (inclusive-range cube-x)
+          y (inclusive-range cube-y)
+          z (inclusive-range cube-z)
+          w (inclusive-range cube-w)]
+      [x y z w]))) 
 ```
 
-The first beefy function is `possible-indexes`, with its coordinating function `all-possible-indexes`.
-`possible-indexes` takes in the list of all `ticket-pairs` and the total number of fields in the tickets, and then
-a single `field` rule definition of form `["name" [low1 high1] [low2 high2]]` from problem state. We run a reducing
-function, starting with a set of all possible indexes, and then we look at every ticket pair. If that pair's value
-doesn't comply with the rule, remove that pair's index from the set of possible indexes. There's a whole bunch of
-extra calculations going on, but this algorithm is still very fast. As a reminder to my future self -- we use `dissoc`
-to remove a mapping from a map, but `disj` to remove a value from a set. Why one function can't do both...
-
-Then `all-possible-fields` just maps each field to the set of possible indexes, and throws it all into a map.
+Let's keep stepping back.  We can return all neighbors of a point in 3 or 4 dimensions, and we
+can take a generation (set of active points) and return the points in the cube that we need to
+inspect in the next generation. We want to build a function called `next-point`, which calculates
+whether a point will be active or inactive in the next generation. For this, we need to calculate
+the number of active neighbors, where we find all neighbors of that point and count the number
+that are currently active. Then we use the logic of looking for 2 or 3 neighbors based on the
+current state.
 
 ```clojure
-(defn possible-indexes [ticket-pairs num-fields [name [low1 high1] [low2 high2]]]
-  (->> (reduce (fn [acc [idx v]]
-                 (if (or (<= low1 v high1) (<= low2 v high2))
-                   acc
-                   (disj acc idx)))
-               (set (range num-fields))
-               ticket-pairs)
-       (vector name)))
-
-(defn all-possible-indexes [fields nearby-ticket-pairs]
-  (->> fields
-       (map #(possible-indexes nearby-ticket-pairs (count fields) %))
-       (into {})))
+(defn num-active-neighbors [active-points neighbor-fn point]
+  (->> (neighbor-fn point)
+       (filter #(active-points %))
+       count))
+
+(defn next-point [active-points neighbor-fn point]
+  (let [actives (num-active-neighbors active-points neighbor-fn point)]
+    (if (active-points point)
+      (contains? #{2 3} actives)
+      (= 3 actives))))
 ```
-Armed with the possible fields, our goal is to use `field-mappings` to actually decide which field belongs to which
-index. We use a simple `loop-recur`, starting with all fields being `unsolved`, and moving them one-by-one into the
-`solved` set. In each loop, we find one field that only has one index that is valid and hasn't been claimed yet by
-another field.  Knowing the field name and its singular index, we use `remove-all-traces` to eliminate that index
-from all remaining fields' set of indexes, and loop again.
+
+Almost done. `next-board` takes in a board and returns the next set of active points, and this
+is now just a coordinator of other functions. Starting from the current board, we identify the
+bounding cube, translate that into all of the points within the cube, keep only the points that
+are active in the next generation, and wrap those points up into a new set.
 
 ```clojure
-(defn remove-all-traces [possible-indexes index]
-  (loop [fields possible-indexes, keys (keys possible-indexes)]
-    (if-let [k (first keys)]
-      (recur (update fields k #(disj % index))
-             (rest keys))
-      fields)))
-
-(defn field-mappings [fields nearby-ticket-pairs]
-  (loop [unsolved (all-possible-indexes fields nearby-ticket-pairs)
-         solved {}]
-    (if (empty? unsolved)
-      solved
-      (let [[name actual-index] (->> unsolved
-                                     (keep (fn [[name indexes]]
-                                             (when (= 1 (count indexes))
-                                               [name (first indexes)])))
-                                     first)]
-        (recur (-> unsolved
-                   (dissoc name)
-                   (remove-all-traces actual-index))
-               (assoc solved name actual-index))))))
+(defn next-board [active-points neighbor-fn]
+  (->> active-points
+       bounding-cube
+       points-in-cube
+       (keep #(when (next-point active-points neighbor-fn %) %))
+       set))
 ```
 
-Finally, `part2` puts the pieces together. Starting with the input, we parse it, identify the valid tickets, flatten
-them into ticket pairs, and identify the mappings. With the correct mappings in-place, we use a `keep-when` to pick
-the fields whose name starts with `departure`, map each to the value that that index in `my-ticket`, and multiple the
-values together.
+Finally, we have our `solve` function and the tiny `part1` and `part2` functions. In `solve`,
+we set up a sequence of all generations of boards, using `(iterate next-board)`.  Then we grab
+the 6th generation and count up the number of active points.
 
 ```clojure
-(defn part2 [input]
-  (let [{:keys [fields my-ticket] :as parsed} (parse-input input)
-        valid-tickets (valid-tickets-only parsed)
-        nearby-ticket-pairs (ticket-pairs valid-tickets)
-        mappings (field-mappings fields nearby-ticket-pairs)]
-    (->> mappings
-         (keep (fn [[name idx]]
-                 (when (str/starts-with? name "departure") (get my-ticket idx))))
-         (apply *))))
-```
-
-All in all, there's a bunch of code here, but it's all reasonably straightforward... now that it's done!
+(defn solve [input neighbor-fn]
+  (let [active-seq (->> input
+                        parse-input
+                        (iterate #(next-board % neighbor-fn)))]
+    (count (nth active-seq 6))))
+
+(defn part1 [input] (solve input neighbors-3d))
+(defn part2 [input] (solve input neighbors-4d))
+```

src/advent_2020_clojure/day17.clj

@@ -25,15 +25,13 @@
             [(dec (apply min values)) (inc (apply max values))]))
         [0 1 2 3]))
 
-(defn inclusive-range [[low high]]
-  (range low (inc high)))
-
 (defn points-in-cube [[cube-x cube-y cube-z cube-w]]
-  (for [x (inclusive-range cube-x)
-        y (inclusive-range cube-y)
-        z (inclusive-range cube-z)
-        w (inclusive-range cube-w)]
-    [x y z w]))
+  (letfn [(inclusive-range [[low high]] (range low (inc high)))]
+    (for [x (inclusive-range cube-x)
+          y (inclusive-range cube-y)
+          z (inclusive-range cube-z)
+          w (inclusive-range cube-w)]
+      [x y z w])))
 
 (defn num-active-neighbors [active-points neighbor-fn point]
   (->> (neighbor-fn point)