This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

## 2018-12-14

## Channels

- # adventofcode (107)
- # aleph (1)
- # announcements (8)
- # beginners (57)
- # boot (3)
- # braveandtrue (18)
- # calva (374)
- # cider (6)
- # cljdoc (8)
- # cljs-dev (140)
- # clojure (199)
- # clojure-berlin (5)
- # clojure-europe (3)
- # clojure-finland (1)
- # clojure-hamburg (4)
- # clojure-italy (17)
- # clojure-nl (16)
- # clojure-spec (2)
- # clojure-uk (70)
- # clojurescript (29)
- # component (2)
- # cursive (10)
- # datomic (44)
- # docker (1)
- # figwheel (3)
- # fulcro (13)
- # immutant (2)
- # juxt (5)
- # leiningen (53)
- # nrepl (3)
- # off-topic (7)
- # pedestal (3)
- # re-frame (7)
- # ring (3)
- # ring-swagger (5)
- # rum (5)
- # shadow-cljs (14)
- # spacemacs (6)
- # specter (12)
- # tools-deps (11)
- # unrepl (11)
- # vim (7)

@pesterhazy https://github.com/pesterhazy/advent2018/blob/master/src/advent/puzzle13.clj#L139-L147

I'm not sure if I had more than 2 carts headed to the same point on the same tick, but I did have a bug when a moving cart collides with a cart that hasn't yet moved on the current tick. (The not-yet-moved cart was not being deleted correctly.)

You might try using `group-by`

and `(map count carts-generations)`

to verify that the cart collection cleanly removes exactly 2 carts instead of 1 or 3 at a time.

I just did loop/recur, could not come up with anything readable but not excessively wasteful with seq api

looks reply https://github.com/akovantsev/adventofcode/blob/master/src/adventofcode/2018/day13.clj

I think Is pretty readable, and not that long: https://github.com/Average-user/adventofcode-clj-2018/blob/master/src/adventofcode_clj_2018/day13.clj

Day 13: https://github.com/mfikes/advent-of-code/blob/master/src/advent_2018/day_13.cljc

https://github.com/taylorwood/advent-of-code/blob/master/src/advent_of_code/2018/13.clj

My part2 examples for day 14 make no sense

Does someone have part1 solved and can send me just the descriptions please??

part 1 and 2. The thing is that I probably need your part 1 input to understand the part 2 input because I guess we have different examples

Thanks a lot

This one didn’t feel too hard, except it took me a while to understand part 2 objective

I suspect we have an error.

Could you explain part2? My examples just give me the 5 five digits of each of the 10 digits from part two. That doesn’t seem right

You have to keep generating recipes until the sequence of individual digits from your input appear as scores

🙈 I still don’t get it

If your input is 1982, then you have to keep generating recipes until your sequence of recipes contains a subsequence of [1 9 8 2]

one of my examples is “92510 first appears after 18 recipes.”

there’s no 18 there?!

why five digits?

@U0A7TVBLN what it means is that the sequence ending “92510” has 18 prior recipe numbers

what would it look like for an input of 2?

oh!!! Backwards!!!

I **think** I got it now

Thanks for the help!!

I ran my attempt over the 4 digits sequences in the examples, and it works fine. I run it over my 6 digit puzzle input, and it’s still going.

subvec really sped it up for me

hmm - I must be making a serious mistake in something. I’m only getting about 10k iterations/sec

@U3DAE8HMG, are you still here?

Keep in mind you can have up to two digits appended to the end; you can't just check the very end of the vector for the pattern!

yes, I’d remembered that, but my 1am coding made a mistake with it. So while I was checking for more than just the very end, I wasn’t doing it right

Thanks for the help. I understand the problem now

hm, also for me part2 is taking long. I'm using subvec and I'm also not repeating the lookup in the middle of the vector, but only at the end

```
(ns adventofcode.2018.day14)
(def day-input 846601)
(def day-input-vec [8 4 6 6 0 1])
(set! *unchecked-math* true)
(def initial-state {:workers #{0 1}
:table [3 7]})
(defn iteration [{:keys [workers table]}]
(let [scores (map (partial nth table)
workers)
recipe-sum (reduce + scores)
new-recipes (if (< recipe-sum 10) [recipe-sum]
[(quot recipe-sum 10) (rem recipe-sum 10)])
new-table (reduce conj table new-recipes)]
{:workers (mapv (fn [index] (mod (+ index (inc (nth table index)))
(count new-table)))
workers)
:table new-table}))
(defn compute-score-after [n]
(subvec (->> (iterate iteration initial-state)
(drop-while #(< (count (:table %))
(+ 10 n)))
first
:table)
n (+ n 10))
)
(defn contains-sequence-at-end? [table sequence]
(let [c1 (count table)
c2 (count sequence)]
(and (>= c1 c2)
(= sequence (subvec table (- c1 c2)))))
)
(defn solution2 [input]
(->> (nth (iterate iteration initial-state) (count input))
(iterate iteration)
(drop-while (comp not #(contains-sequence-at-end? (:table %) input)))
first
:table
(drop-last (count input))
(count)))
```

@U07FP7QJ0 a gist is better maybe: https://gist.github.com/Heliosmaster/4971270311f00f3f8af1ccb7c0d29adf

Looking at it from Visualvm it seems your bottleneck is in iteration. `table`

is always a vector, right? In that case you should avoid `nth`

, as it will treat the vector as a seq and walk it element by element. Use `get`

instead.

You're testing for the pattern at the end, but you're adding not just one, but possibly *two* digits at the end.

@U1YPTG4UF right, i should check twice to be sure

@U07FP7QJ0 Is that right, I thought nth on vector is comparable to an array lookup: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentVector.java#L161

it's still spending a lot of its time in those first few lines of `iteration`

, just doing the `map`

+`reduce` to compute the score...

Is `(set! *unchecked-math* true)`

really necessary?

Mine takes 34s w/ subvec 😞 https://github.com/benfle/advent-of-code-2018/blob/master/day14.clj

not relevant, but this could be just `def`

https://github.com/benfle/advent-of-code-2018/blob/master/day14.clj#L14-L17

"Elapsed time: 36315.651048 msecs" not optimized for performance `p2`

(somewhat readable though)

https://github.com/akovantsev/adventofcode/blob/master/src/adventofcode/2018/day14.clj#L53-L72

I stole your `adjust-idx`

function and it gave me a 10x speed up. Seems like my run cost was dominated by the `rem`

function call to wrap the index back into the correct range. Successive subtraction is far cheaper. Now I get 2-3 seconds for part 2, down from 25-30 seconds.

nice time!
`adjust-idx`

probably could be a bit faster with `loop`

in it instead of seqs, but I didn't bother to test it out

I retract everything! I introduced a typo when using `adjust-idx`

that resulted in my algorithm finding the wrong answer, which appeared much earlier in the sequence. So the execution overhead didn't change significantly, I was just running through 1/10th the iterations. I'm back above 20 seconds! :man-facepalming:

I got 4.3s in the end (2am) 😳 I had an optimization to only look when one of the last 2 digits matched the final digit of my input, and I messed it up, which is what kept me up late. But when it worked, it was fast

I wanted to avoid unnecessary subvecs, so I finished my loop with something like this pseudocode:

```
(if (= last-input-digit last-digit-added)
(test-the-trailing-subvec recipes input)
(if (> last-value-added 9) ;; we know that the final input digit is 1
(test-the-second-last-trailing-subvec recipes input)
(recur recipes first-elf second-elf)))
```

Dang I missed it. But I also needed a day off programming. Did today’s part 2 literally at work so I would have the evening free while I was waiting for a build (several times) containing some fixes from one of my devs. This was my last working day today so there was no pressure to start anything new

Nice! Yeah I’ve had to take a few days from AoC myself. Glad to have a little lead time before the stream 🙂

One idea I had, that may be vaporware - you can 'replay' strings you've seen before, up to the point where one of the elves wrapped around to the beginning. Since those substrings have already been seen, the pattern could only show up at the boundary between that memoized string and the current recipe string. This would probably accelerate as you got further down the line... Then again, might be the cost of holding all that in memory / calculating all these strings would be inordinately costly. Managing them would certainly be a pain.

My day 14: https://github.com/pesterhazy/advent2018/blob/master/src/advent/puzzle14.clj

Proudly unoptimized

Is it wrong that my first response to being told that my answer is too big is to try (dec answer) ?

And then not fix the bug...