Clojurians Log v2

lol so some of us matched the border line not the tree. :)

Oh, duh! I got the right result for the example, but not for my input.

also, looks like the AIs are running out of steam... leader clocks in at 15 minutes.

https://github.com/Maravedis/advent_code/blob/master/src/advent_of_code/2024/15.clj Lots and lots of lines of code today. Gotta love asymmetry.

Finally, I managed to solve it. In my solution today there's only one thing I like

(def scale-up #(str/escape % {\# "##" \. ".." \@ "@." \O "[]"}))

I enjoyed this one; the boxes being different ASCII meant my "move in direction and give me coords to replace" just overloaded the \[ \] cases. https://github.com/tildedave/advent-of-code/blob/main/src/advent2024/day15.clj

It works pretty fast, but the code is quite messy https://github.com/zelark/AoC/blob/master/src/zelark/aoc_2024/day_15.clj

Damn! It's just a tree again 🎄

i'm confused. there're 20 lines of robot moves.

just add the gps value of each up?

I'm not sure what you're asking.

process all robot lines to get final box coords, add gps value of each

The thing to calculate is based on the coordinates of the boxes, not the robot.

the two examples each has one line of robot moves. my input file has 20 lines of moves

> The moves form a single giant sequence; they are broken into multiple lines just to make copy-pasting easier. Newlines within the move sequence should be ignored.

arrr... ok thanks. treat them as one line.

And here’s todays, and as usual recursion for the win: https://github.com/bhauman/adv2024/blob/main/src/adv2024/day15/sol.clj BTW the play went great yesterday! Community theater is a wonderful thing

Congrats!

Inspired by @roklenarcic's solution, I refactored mine. It works a bit slower than my previous one, but the code is pretty readable and concise now https://github.com/zelark/AoC/blob/master/src/zelark/aoc_2024/day_15.clj

Gotta be careful with recursion, you can have paths merging, and you can arrive at the same box twice through different paths

[]
    [][]
   []  []
    [][]
     []

had to spit out frames into files to find I am moving air sometimes:

...@.. v ...... vs. ......
..[]..   ...@..     ...@..
.[]...   ..[]..     ..[]..
...[].   .[]...     .[][].
......   ...[].     ......

I'm not sure getting to the same box through different paths is bad; if you're pushing up or down the "next square" destination would be the same

so it's just duplicative vs a true conflict

depends on what you are doing

> It’s probably lucky that there’s no such occurrence How do you know it? There are 20k movements, so it might happen at some point

Just checked for this input, works fine ; #............# ; #.....[].....# ; #....[][]....# ; #...[]..[]...# ; #....[][]....# ; #.....[].....# ; #.....@......# ; #............# ; #............# ; #.....[].....# ; #....[][]....# ; #...[]..[]...# ; #....[][]....# ; #.....[].....# ; #.....@......# ; #............# ; ############## ; #.....[].....# ; #....[][]....# ; #...[]..[]...# ; #....[][]....# ; #.....[].....# ; #.....@......# ; #............#

The most useful thing I learned with this day is an easy way to write "Gather all elements of a a seq that satisfy a pred, and keep the first element that doesn't" with split-with:

(let [[boxes [first-non-box]] (split-with box-set ())

I spent 1hour on calculating the score for part 2. I interpreted "are measured from the edge of the map to the closest edge of the box in question" in the wrong way and was calculating the distance to the closest edge. So a box at the right and bottom most would have a distance of [1 1]. It didn't work 🤣

whether you push left/push right should have the same result (the same boxes move to the same places). I used a distinct in my implementation. the symmetry of left/right having the same "physical" results should mean no conflicts

my grid was correct so pushing was correct. Only the score calculation was wrong because of the interpretation

My favorite tricks for this one was to rely on persistent vectors to quickly check if the warehouse changed after a move. (= wh next-wh) I was initially returning nil for such case but it made the recursion more annoying to deal with

So recursion works for diamond shaped box stacks bc you are in actuality pushing up one half of the initial box and getting that result. You then use that result (where one half of the box is still down) as input and then pushing that remaining half box up.

; #............#
; #.....[].....#
; #....[][]....#
; #...[]..[]...#
; #....[][]....#
; #.....[].....#
; #.....@......#
; #............#

; #.....[].....#
; #....[]......#
; #...[].[]....#
; #....[].[]...#
; #.....[[]....#
; #.....@].....#
; #............#
; #............#

; #.....[].....#
; #....[][]....#
; #...[]..[]...#
; #....[][]....#
; #.....[].....#
; #.....@......#
; #............#
; #............#

And I gotta say I prefer the reasoning in the recursive method. For example this is all the logic for movement for part 1

(defn try-move-over [from dir wm]
  (let [to (mapv + from dir)
        to-ch   (wm to)]
    (when (not= \# to-ch)
      ;; either the next one is blank and we move to that space
      ;; or we try to move the thing that's in our way over
      (when-let [res (if (nil? to-ch) wm (try-move-over to dir wm))]
        (-> res
            (dissoc from)
            (assoc to (wm from)))))))

(defn move [[rb wm :as state] dirch]
  (let [dir (directions dirch)]
    (or
     (when-let [res (try-move-over rb dir wm)]
       [(mapv + rb dir) res])
     state)))

yeah, my p1 was readable too :) "maybe find the furthest space and put box there, adjust @"

L (fn [[x y]] [(dec x) y])
          R (fn [[x y]] [(inc x) y])
          U (fn [[x y]] [x (dec y)])
          D (fn [[x y]] [x (inc y)])

          dir->f1 {\< L \^ U \> R \v D}

          push1  (fn [[xy0 xy->z] dir]
                   (blet [f       (dir->f1 dir)
                          box?    #(-> % xy->z #{\O})
                          wall?   #(-> % xy->z #{\#})
                          space?  #(-> % xy->z #{\.})
                          xy1     (f xy0)
                          xyN     (->> xy1 (iterate f) (drop-while box?) first)
                          xy->z+  (assoc xy->z xy0 \. xy1 \@)
                          xy->z++ (assoc xy->z xy0 \. xy1 \@ xy2 \O)]
                     (cond
                       (wall? xy1)  [xy0 xy->z]
                       (space? xy1) [xy1 xy->z+]
                       (space? xyN) [xy1 xy->z++]
                       :else        [xy0 xy->z])))

https://github.com/rjray/advent-2024-clojure/blob/master/src/advent_of_code/day15.clj I'm wont to even share this. I finished part 1 pretty well (albeit late for having been at a hockey game past the point of the puzzle unlocking). But part 2? I struggled with it for hours before choosing to go to sleep. Got up and resumed it, but while I could get the correct answers for the test sets, I kept getting the wrong answer for the puzzle. After some number of hours (punctuated by household chores to clear my head), I gave up and tried a short and succinct search-like algorithm I found in a Python solution on reddit (URL to the code in the comments of my code). Took some debugging due to differences in programming style, but it got the answer. And I got a very different view on the puzzle itself; the Python author had been able to solve both 1 and 2 with the same two functions. One of those cases where I feel like I should have been able to think of this on my own, but I didn't.

I don't like it... too verbose 😕 https://github.com/genmeblog/advent-of-code/blob/master/src/advent_of_code_2024/day15.clj

@jvuillermet > I spent 1hour on calculating the score for part 2. I interpreted "are measured from the edge of the map to the closest edge of the box in question" in the wrong way and was calculating the distance to the closest edge. > > So a box at the right and bottom most would have a distance of [1 1]. It didn't work me too! that's such a weird way to phrase it. I had every variation of this imaginable

(defn gps-sum' [[_ boxes]]
  (map (fn [[i j]] (+ (* 100 (min i (- (dec h) i)))
                      (min j (- (dec w) j) (inc j) (- (dec w) (inc j)))))
       boxes))

Haha glad to know if I'm not the only one

https://gitlab.com/maximoburrito/advent2024/-/blob/main/src/day15/main.clj This took way to long, but I enjoyed it. I used an grid update technique I hadn't tried before for part2 and it worked quite well.

Annoying to code this 🙂

https://gist.github.com/RokLenarcic/f769245ab2491bf82c580e49a850b71e

https://github.com/erdos/advent-of-code/blob/master/2024/day15.clj

I think I can make this way shorter

pretty fun (bug-hunting in a utility function aside...)

Hot damn, this reduced a lot: https://gist.github.com/RokLenarcic/f769245ab2491bf82c580e49a850b71e

updated with a much shorter solution