Clojurians Log v2

Nice weekend everyone? 😄

got day9.. should have used a map and not vars for the loop/recur

too bad you can't change it 🙂 (git records all of our sins)

force push to the rescue

lol. i like having the history of my refinements for AoC

@minikomi Nice solution! Your throw may make things more robust, but if the input is valid, I think you should be able to take the three cases \, \newline, and \! and eliminate them, if you take the result-expr for \, and use it instead of the (throw ...).

yeah, i just had it there to refine my solution.. catch (ha!) the times it went awry.

Instead of trying to say it in words, this variation on your solution works for me: https://gist.github.com/mfikes/57c1b666c30bb5fd98b235df87b5c189

oh, is cancel guaranteed to only be in garbage? that's good then!

Right, I think you can interpret the problem definition that way. And it seems to be borne out by the input data.

cool

there 🙂 credited you in the commit heh

man this wording for day 10 part 2 is confusing.

If the suffix is added, there's 8 3, 4, 1, 5, 17, 31, 73, 47, 23 as the steps.. but the skip sequence carried over is 4 ?

rather than 9, since 9 steps have occured..?

oh, ok i got it.

reductions 💌

I've gotta search for the number of times part 2 has been reduce -> reductions

I've used Clojure for all three years, and I feel like some of the earlier problems are easier to solve in a procedural style, but I feel like functional languages really start to shine after a few days.

Though the hash cracking one from... last year?... was a bit tough... I had to learn more about Java interop to make it fast

I'd love to go through and solve these with different paradigms, hone a sense for what gets easier and what gets harder

Also had Proto Repl finally set up on my laptop for this round 😄

@fellshard same here, but right now trying to decide between “pretty” with reduce/`reductions` vs 30x faster with apply

(apply str (map #(format "%02x" %) xored)) Was pretty happy wit that hexidecimal-string-conversion 😄

format is such a beast

Hi all! @fellshard Indeed, “coda” is a musical term; It literally means “tail” in Italian. It refers to the bars that come after a repeating part. I don’t know how it popped into my mind, but I like it better than “tail” which can be confusing when destructuring linked lists.

Day 11: https://github.com/orestis/adventofcode/blob/master/clojure/aoc/src/aoc/2017_day11.clj

Today I didn’t have much time to arrive to the solution from first principles; I had to lookup hex grids and how they work.

I’ve included a link to a nice article in my solution code.

Day 11 is a bit difficult for me

I’ll peek at @orestis's link

Anyone who wants a SPOILER or hint, peek in this thread

https://twitter.com/EsthervdSHU/status/940160750303268864/photo/1

my solution for today: https://github.com/skazhy/advent/blob/master/src/advent/2017/day11.clj with a handy ascii art on how the coordinates are handled.

In my opinion, today’s challenge lent itself well to one of the most elegant & concise solutions this year so far https://github.com/axelarge/advent-of-code/blob/master/src/advent_of_code/2017/day11.clj

@mikelis.vindavs That is indeed very nice.

Did anyone else get emotional while reading > “It’s my child process,” she says, “he’s gotten lost in an infinite grid!”

https://repl.it/repls/BoldAzureCuscus here’s mine

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

cube coordinates everywhere 😄

@mfikes isomorphic once again

I have to admit without the hint about cube coordinates I would still be thinking right now

Me too. I did some quick research and chose that coordinate system because it makes calculating distance trivial.

The photo in the spoiler thread above did it for me

I’m wrote a game on hex grid once so it was a no-brainer

I solved it without cube coordinates, by using the simplified versions of de diagonals for north and south. So NE + NW = (1,1) + (1,-1) = (2,0). Calculation is simple after that, similar to using a Z-axis.

@erwin link?

https://github.com/ekroon/adventofcode2017/blob/master/src/adventofcode/day11.clj

nice approach with the input resolving directly to coordinate tuples 👍:skin-tone-2:

@erwin nice!

it seems so simple once you see it

today was fast to compensate for yesterday, which was very slow for me 😁

input/input

?

woo, i forgot that reductions exists

oow, still a defect? wrote the solution in a repl / nightcode at work and pasted it in github in one file. Let me fix that.

There is an interesting perf anomaly with @erwin's solve-2 where it runs in 124 ms for me in Clojure vs. 15 ms in self-hosted ClojureScript. Hrm.

@mfikes sanity check: do they yield the same outcome?

Yes, 1493

This was the page I hit for the research I did. It has incredible visualizations of the coordinate systems. https://www.redblobgames.com/grids/hexagons/

I hit that one too and then I tried the q layouts, but had problems calculating the distance

I scrolled down to the Distances section and saw that Cube coordinates has a nice formula.

yeah, that’s the same system as on the photograph, but I was nearly awake then 😉

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

ok just finished, I spent some time on paper trying to devine the properties of the system first

now to see what others did

+1 for the Christmas ascii art @bhauman

@borkdude thats from the first advent of code

oh I see others did this as well, congrats @mikelis.vindavs!!

and @erwin

oh wait yours is different but I think logically equivalent

Interesting. @bhauman's also exhibits that odd perf anomaly where part 2 is much faster in Planck.

90 ms vs. 30 ms

well its the same work, so maybe its warmed up

Planck starts off at 90 ms but then drops down to 30 ms. My guess (based on some stuff Timothy Baldridge was saying): JavaScriptCore uses a tracing JIT, so after it sees execution, it can compile things to machine code that relies purely on primitives. There is evidently something tracing JITs can do that the Java VM can't do with its current implementation, but I don't fully appreciate what is going on.

Perhaps the day 11 problem happens to be highly amenable to tracing analysis, involving a tight loop of math at its core.

This sounds like an Advent of Code problem in itself

javascript engines are freaking crazy

Day 12: > Part 1: some random array walking > Part 2: perhaps the day 12 problem happens to be highly amenable to tracing analysis, involving a tight loop of math at its core. > Determine the time spent after running the algorithm on the output of part 1.

FWIW, my solution also exhibits the odd perf anomaly: part-2 is 124 ms in Clojure and 19 ms in Planck / JavaScriptCore.

using the tips and tricks from day5 i see some boxed math and reflection optimization possibilities, so I would say that it is indeed the tracing jit

FWIW, nooga's is also exhibiting the same phenomenon

@mfikes what about your own?

https://clojurians.slack.com/archives/C0GLTDB2T/p1513001852000049

https://github.com/ekroon/adventofcode2017/commit/95d397e70fb1485a16a0a9ae30a61a0c80117320 adding ^int ^int ^int ... and it is 10ms and 20 ms

@mfikes oh sorry 🙂

Yeah, for me the call to Math/max was using reflection. 😱 My solution dropped from 124 ms to 8 ms with https://github.com/mfikes/advent-of-code/commit/8b71e9a87f7e9dee970fc6f5176edf30bb2569db#diff-71207370594c4dd13d58690ffbff0646

try using (defn abs [n] (max n (- n))) instead

So, in short, no tracing JIT magic, just plain old reflection being damned slow.

OK

would probably have same effect

@alonoaky Yep

wasn’t this kind of type hint also valid? (defn ^long distance […] …). When I call distance from the REPL it works fine

But when I call it from another form, I get: java.lang.IllegalArgumentException: Unable to resolve classname: clojure.core$long@462e36ad

Short snippet of what I mean:

(defn ^long d [] 1)
(Math/abs (d))

@borkdude I think that's where they go in ClojureScript, but in Clojure

(defn d ^long [] 1)

I'm not so sure, TBH.

cool, 12 ms for both parts now

why can’t I use ^longs here (instead of annotating each element): https://github.com/borkdude/aoc2017/blob/master/src/day11.clj#L28

here I could: https://github.com/borkdude/aoc2017/blob/master/src/day11.clj#L19

Hmm. ^longs means a primitive array of ^long right?

> What about when you have a sequence of values, all of a uniform type? Clojure provides a number of special hints for these cases, namely ^ints, ^floats, ^longs, and ^doubles. https://github.com/clojure-cookbook/clojure-cookbook/blob/master/08_deployment-and-distribution/8-05_type-hinting.asciidoc

works for apply +

maybe it’s not supported in a destructuring form

I’ll ask in #clojure

This works though:

(defn f [[x y z :as ^longs args]]
    (apply + args))

so I think as long as you’re using the entire sequence, the type hint will work, but not for individually destructured elements

Turns out + doesn’t need the type hint, so it’s bogus anyway

This is a bit funny. This give a type hint warning:

(defn f [[x y z]]
  (+ x y z))

(defn f [[x y z]]
  (apply + [x y z]))

I guess because a vector cannot contain primitives anyway

Hmm @borkdude I don't get a reflection warning on your first form (in Clojure 1.9.0)

Or, what do you mean by "type hint warning"?

@mfikes (set! *unchecked-math* :warn-on-boxed)

Ahh, that's cool. By doing (set! *unchecked-math* :warn-on-boxed) you are essentially saying you want the (+ ...) form to use unchecked math (presumably replacing clojure.core/+ with clojure.core/unchecked-add in some way at compile time), but it is warning that it can't actually employ unchecked math because the values are boxed as Object instances? (Which can be fixed by type hinting them.) But in the second form, + is not being compiled—it is being passed in as a higher-order function to apply, so the result is that you get checked arithmetic regardless.

aaah 💡

I'd like to know why you can't make the second form use unchecked arithmetic by changing it to:

(defn f [[x y z]]
  (reduce unchecked-add [x y z]))

vectors can’t contain primitives, but not sure if I understand the problem

OK, so

(unchecked-add Long/MAX_VALUE Long/MAX_VALUE)

(apply unchecked-add [Long/MAX_VALUE Long/MAX_VALUE])

Also no

(let [ua unchecked-add] (ua Long/MAX_VALUE Long/MAX_VALUE))

same reason as before, inlining doesn’t work with higher order?

I think this is why Zach wrote https://github.com/ztellman/primitive-math

I like Zach's intro here https://groups.google.com/forum/#!msg/clojure/d89gjX_5Om8/KgBcIORMGYYJ

the lib is now “archived”?

I finished an alternate solution for day11 that doesn't use a coordinate system https://github.com/thegeez/clj-advent-of-code-2017/blob/master/src/advent/day11.clj#L166

cool, so many different approaches

@thegeez Care to give us the tl;dr explanation?

replacement-moves turns two moves into either zero, one or two moves. For instance [:n :s] is the same as doing nothing, [:n :se] is the same as take a single :se step one by one the steps from moves are added to the shortest path, where the added step might undo a previous step, combine with another step into a single step or the step is added

very creative!

The first version of that took way too long for part two, but now it works