Clojurians Log v2

it is lazy, which is why you're getting the stack overflow. consider this

(def x (reduce concat (map #(list %) (range 100000))))

(first x)

I'll talk about this on the stream today, it's one of those surprising clojure gotchas.

good morning

Today, I hoped there was a part 3.

im still banging my head on yesterday’s. trying to do a clara.rules version. I figured out Part I, but Part II is getting me

(defrecord ContainerBag [type contained-bags])

(defrecord IntermediateBag [parent-type type])

(defrecord GoldBag [parent-type])

(defrule produce-intermediate-bags
  [ContainerBag
   (= ?type type)
   (= ?contained-bags contained-bags)
   (seq contained-bags)]
  =>
  (when (seq ?contained-bags)
    (insert-all!
     (mapv (fn [[kind num]]
             (if (= kind "shiny gold")
               (map->GoldBag {:parent-type ?type})
               (map->IntermediateBag {:parent-type ?type
                                      :type kind})))
           ?contained-bags))))

(defrule indirect-gold-bags
  [ContainerBag
   (= ?type type)]
  [IntermediateBag
   (= ?type parent-type)
   (= ?intermediate-type type)]
  [GoldBag
   (= ?intermediate-type parent-type)]
  =>
  (insert! (map->GoldBag {:parent-type ?type})))

(defquery gold-bags []
  [?gold-bags <- (acc/distinct :parent-type) :from [GoldBag]])

(defquery intermediate-bags []
  [?intermediate-bags <- IntermediateBag])

(defn run-rules []
  (-> (mk-session :cache false)
      (insert-all (doall (for [[k vs] (parse input)]
                           (map->ContainerBag {:type k
                                               :contained-bags vs}))))
      (fire-rules)))

;; Part I
(-> (run-rules)
    (query gold-bags)
    first
    :?gold-bags
    count)
;; => 179

Today's was a lot of fun!

Hope they will continue this series as it was last year.

unfortunately, this is unreadable in slack thread even on 15" screen due to line wrapping :(

Bombed out on 7…. Caught up on 8.. I am guessing this is one worth building really good tests around since they will probably have us refactor it a bunch??

For day 7, part 2. What does this mean "becomes topologically impractical"?

I solved part1 as a graph, then reverseed the graph and counted from shiny gold to all the unique nodes i can hit. But I dont know what it means that i have to take into account topologically impractical

the statement means to go as deep as data, even if in practice nobody would be able nest so many bags in each other

be sure to count all of the bags, even if the nesting becomes topologically impractical!

https://mobile.twitter.com/pauladozsa/status/1336061757933187072

thank you, so it's like a joke rather than soemthing technical I have to consider?

that makes sense now.

Yes, there are usually only several statements relevant and the rest is for Christmas atmosphere and laughs

Havent looked at day 8 yet, is it int code computer all over again ? 😄

Smells like it.. ;-)

Part 2 of day 8. I hate it a bit. But now dinner and reading Stravaganza with my kids. Hopefully that will cleanse my thought patterns.

May the Force be with you. Brute force.

I probably wrote too much code

Hello everybody and welcome to day8 😄 I finished todays task rather fast but I am left wondering if there is more clever solution to second part than just generating all permutations and executing them so this will probably occupy my mind for a little bit. It still completed in less than 70 milliseconds so ¯\(ツ)/¯ but I felt a little like cheating by bruteing it 😄

I also went for the brute force

can't really think of another way tbf

*spoiler alert click on thread only after finishing the task 🙂

My gut feeling is that there might be some possible way to do simple heuristics over the code and analyze the bits that will surely loop as the loops are not conditional so they are bound to be executed ever time.

but to be honest this will probably take much more code and in the end will execute slower than basic permutation generation ;d

so as I mentioned my gut feeling is that because jumps are not conditional you could write code that would analyze the source and identify the jumps that would 100% end in infinite loop

yeah maybe it's possible

another thing is that you probably don't need to re-run the whole simulation every time with the changed instructions set (which is what I did at least)

you would only need to branch out every time there is a nop or a jmp

yeah probably

saw the pinned msg, moved my link there

good idea, you could explore the "code space" like tree

moving my solution here https://github.com/AndreaCrotti/advent2020/blob/master/src/problems.clj#L257

ah yes my bad I did the same

actually you don't need to generate all permutations upfront, you can generate lazy list of permutations and stop when you find first one which terminates properly.

well I generated all the possible replacements https://github.com/AndreaCrotti/advent2020/blob/master/src/problems.clj#L294 which I guess would not be that expensive anyway

it's running the simulation that in theory is the expensive thing

but actually in my solution I'm calling terminates? on all the permutations tbf 😄 so yeah could definitively improve that

You could represent the program as a directed graph and run an algorithm to find the minimal cycle-breaking set. But that doesn't seem easy after quick googling :)

Well with loom it would be doable

The graph algorithm is done at least

Bruted it. I feel dirty now.