Way too busy for today’s drop.. good luck folks

Well, well. This day's uses a couple of old friends.

yeah, I had to go back to my day10 solution to improve its performance

transients!

Am I missing something? I think (row "flqrgnkx" 0) should return 11110000 although their example grid shows different?

This works though: (= “10100000110000100000000101110000” (row “a0c2017" 0))

oh, wait… https://i.imgur.com/Wyl57tE.jpg

Horrible: I guessed the right answer for part 2 by offsetting it to the example and the wrong output for that one…

but I still have to fix the code 😛

My day 14 is up: https://github.com/borkdude/aoc2017/blob/master/src/day14.clj

my day 14

https://github.com/bhauman/advent-of-clojure-2016/blob/master/src/advent_of_clojure_2017/day14.clj

thank goodness for all the perf work done on day 10

@bhauman Funny, mine is faster for part 2 while I borrowed only your groups function 🙂

my part 1 is much slower though

not sure if it’s my input or something in my code.. looks about the same

yeah get-in is killing me

oh day 10 optimizations, sorry I thought day 12

yeah, I didn’t optimize day 10

also my neighbors function could be improved for speed

I'm pretty sure the fact that you are using .charAt along with a tuned neighbors function is whats making the difference

probably

for part 2

cl-format is killing you on part 1

its a dog yo

the type annotations didn’t matter very much though

@bhauman why is there an 8 here instead of 4? https://github.com/bhauman/advent-of-clojure-2016/blob/master/src/advent_of_clojure_2017/day14.clj#L14

also remember your hardware is showing up consistently faster than mine

16 numbers

@bhauman I’m on a Macbook Pro 15" 2015

well its faster than mine 🙂

mid 2014

I bought it just before the new Macbook Pros came out… I wanted to wait, but hell, I just needed one right then

🙂

did you figure out why I use 8 instead of 4?

Anyway, thanks you for letting me borrow your groups function. I put the credits in the code 😉

It’s one of the most awesome functions I’ve come across so far

no, I’d have to start up a REPL to see what’s going on

I'm iterating over the numbers not the hex characters

1 number = 2 hex chars

ah I see yeah

that probably speeds it up as well

with

(transduce
     (comp
      (map #(Integer/parseInt (str %) 16))
      (map #(Integer/toBinaryString %))
      (map #(format "%4s" %)))
     str
     kh)

I’ll leave the optimization for when it’s really needed today

maybe (transduce ... str ..) isn’t that optimal, I don’t know it will still use StringBuilders that way

Gotcha:

boot.user=> (time (do (reduce str (range 100000)) nil))
“Elapsed time: 14011.548079 msecs”
nil
boot.user=> (time (do (apply str (range 100000)) nil))
“Elapsed time: 6.564031 msecs”
nil

Day 14: https://github.com/mfikes/advent-of-code/blob/master/src/advent_2017/day_14.cljc

Actually the string thing is not where the most time is spent in my code. It’s the knot hash itself which should be optimized.

mfikes: great job. Also revisited two previous days 🙂

But for the future it may be good to know:

boot.user=> (time (do (transduce (map identity) str (range 100000)) nil))
“Elapsed time: 13888.143336 msecs”
nil
boot.user=> (time (do (apply str (range 100000)) nil))
“Elapsed time: 6.55865 msecs”

It looks like @cgrand might be joining the fun. He posted yesterday's https://github.com/cgrand/advent2017/blob/master/src/advent2017/day13.clj

I was miffed that there is a cljs.core/bit-count but in Clojure you need to do interop.

@borkdude

(time (do (transduce (map identity) str (range 100000)) nil))
  "Elapsed time: 16865.420273 msecs"

  (time (do (apply str (range 100000)) nil))
  "Elapsed time: 14.711439 msecs"

  (time (do (transduce (map identity) net.cgrand.xforms.rfs/str (range 100000)) nil))
  "Elapsed time: 7.697859 msecs"

@thegeez expected that to be in there… I might revert my code to the transducer now! 🙂

hmmmmm i wonder if Long/bitCount would fail if you happened to get a negative hash number?

@mfikes ^

and congrats on what looks like a very speedy implementation

@bhauman I suppose for this particular problem it ended up being OK because you permute (range 256) and I have it doing bit-xor chunks 16 at a time. In other words, things stay positive because they fit in long

An example:

user=> (advent-2017.day-10/knot-hash-decimal "adfdf")
[72 206 34 163 109 167 172 101 51 5 47 187 155 72 76 57]

hmmmm

(I cheated a bit by having my day 10 solution provide the underlying vector of numbers.)

as did I good sir, as did I