Clojurians Log v2

I also hard coded boundaries for cycle in part 2 https://github.com/nbardiuk/adventofcode/blob/master/2022/src/day17.clj

semia-utomatic search of cycle segment https://github.com/akovantsev/adventofcode/blob/43cb2bcc0fda8719135af9333c3a7dd003a497cb/src/adventofcode/y2022/day17.clj#L119-L143

@nbardiuk what a beautiful solution — very readable & expressive! I like the use of reductions and cycle , and the reusing of dh in part 2

I wasn’t able to get my clj solution for today to run faster than 3 or so seconds. Whereas my simpler python solution runs in 70ms 😕

then again in py i used a bitmask to represent each line of the stack

yes, my solution is slow. Also I track which point belongs to which original shape for colorful rendering

my comment about the slowness wasn’t directed at you, it was about my own clojure solution 😅 sorry if it sounded that way yes, i noticed that you assoc the keyword for each shape into the map. What are you using to generate that image?

I didn't took it personally, I meant my code is ALSO slow 🙂 I use clojure2d, the file with sketch is not that readable https://github.com/nbardiuk/adventofcode/blob/master/2022/sketch/day17_sketch.clj

nice, i didn’t know about clojure2d

it's great - runs on latest jvm (while quil doesn't) and has documentation site with examples https://clojure2d.github.io/clojure2d/docs/codox/index.html

i also find it surprising that you can find the cycle just by looking at the height differences, that’s so much simpler than what i did — make a “fingerprint” of the last 10 rows, basically the relative max height of each x coordinate

i don’t think either solution would work correctly for all possible inputs though e.g. mine definitely wouldn’t work if there were “caves” under an overhang

or a super tall empty gap on one side which then later gets filled by dropping an I shape down more than 10 rows

yes, last 10 rows are not stable because peaces can fall between cracks. Also heights can repeat while the shape does not.

@mikelis.vindavs “to run faster than 3 or so seconds” Is it for part 1 or part 2?

for part 2

I store the occupied slots as a set of x,y tuples This means that collision tests, but especially fingerprinting (which has to do at least 1 linear search over the entire set to find the max Y coordinate), get slower as the stack gets filled up. What’s interesting is that i tried pruning down the set of coordinates every once in a while, but that only made the whole thing even slower

Interesting, pruning down the set was my first thought when I saw part 2 question.

the cycle occurs pretty fast so it doesn’t get that huge- it always stays below 10k elements

i just realized i can pass in the “max y” from outside, now it all takes 100ms

that’s kind of funny

I ended with this, works relatively fast

(defn reify-rock [state]
  (let [{:keys [rock chamber position height]} state
        [cx cy] position
        [chamber' height'] (reduce (fn [[m h] [x y]]
                                     (let [x' (+ x cx)
                                           y' (+ y cy)]
                                       [(assoc m [x' y'] \#) (max h y')]))
                                   [chamber height]
                                   rock)]
    (assoc state
           :chamber chamber'
           :height height')))

what’s position, is it the bottom left corner of the rock?

and how do you detect cycles for p2?

Yes, it is

For part 2 I did it manually with a notepad 🙃

nice

btw, another finding that was surprising to me

;;(def intersects? (comp seq set/intersection))

(defn intersects? [a b]
  (if (< (count a) (count b))
    (some b a)
    (some a b)))

in general, i keep getting surprised by how ok it is to generate lots of garbage

I enjoyed this one, was able to get something that solves part-2 in about a second: https://github.clerk.garden/alexalemi/clerktudes/commit/2da0d9e6008e02078e524bf6df368a410e11f132/notebooks/advent-2022-17.html

https://gitlab.com/maximoburrito/advent2022/-/blob/main/src/day17/main.clj Part 1 was very fun, though it took much longer than I thought. Part 2 was really tough, but we've had cycle detection problems before so it seemed relatively clear what generally needed to be done. Part2 here is kind of ugly. I dumped my height differences into emacs and played with the buffer a bit to confirm there were cycles and what size they were to write a more targeted solution. It's not my finest clojure, but it works...