This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (129)
- # architecture (10)
- # beginners (163)
- # boot (1)
- # cider (34)
- # cljs-dev (9)
- # clojure (210)
- # clojure-austin (11)
- # clojure-czech (2)
- # clojure-gamedev (1)
- # clojure-greece (67)
- # clojure-italy (2)
- # clojure-russia (8)
- # clojure-spec (36)
- # clojure-uk (54)
- # clojurescript (87)
- # cursive (12)
- # data-science (6)
- # datomic (13)
- # devcards (4)
- # editors (2)
- # emacs (34)
- # figwheel (6)
- # fulcro (147)
- # graphql (17)
- # lumo (54)
- # off-topic (37)
- # om (11)
- # onyx (7)
- # parinfer (10)
- # random (1)
- # re-frame (13)
- # ring (10)
- # ring-swagger (2)
- # sfcljs (1)
- # shadow-cljs (1)
- # spacemacs (32)
- # test-check (4)
- # unrepl (84)
@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
\! and eliminate them, if you take the result-expr for
\, and use it instead of the
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
Right, I think you can interpret the problem definition that way. And it seems to be borne out by the input data.
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
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
@fellshard same here, but right now trying to decide between “pretty” with
reduce/`reductions` vs 30x faster with
(apply str (map #(format "%02x" %) xored))
Was pretty happy wit that hexidecimal-string-conversion 😄
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.
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.
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
Did anyone else get emotional while reading > “It’s my child process,” she says, “he’s gotten lost in an infinite grid!”
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.
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.
nice approach with the input resolving directly to coordinate tuples 👍:skin-tone-2:
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.
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.
ok just finished, I spent some time on paper trying to devine the properties of the system first
Interesting. @bhauman's also exhibits that odd perf anomaly where part 2 is much faster in Planck.
Perhaps the day 11 problem happens to be highly amenable to tracing analysis, involving a tight loop of math at its core.
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:
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
https://github.com/ekroon/adventofcode2017/commit/95d397e70fb1485a16a0a9ae30a61a0c80117320 adding ^int ^int ^int ... and it is 10ms and 20 ms
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
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: [email protected]
@borkdude I think that's where they go in ClojureScript, but in Clojure
(defn d ^long  1)
why can’t I use ^longs here (instead of annotating each element): https://github.com/borkdude/aoc2017/blob/master/src/day11.clj#L28
> 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
so I think as long as you’re using the entire sequence, the type hint will work, but not for individually destructured elements
This is a bit funny. This give a type hint warning:
but this doesn’t
(defn f [[x y z]] (+ x y z))
(defn f [[x y z]] (apply + [x y z]))
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/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.
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]))
(unchecked-add Long/MAX_VALUE Long/MAX_VALUE)
(apply unchecked-add [Long/MAX_VALUE Long/MAX_VALUE])
(let [ua unchecked-add] (ua Long/MAX_VALUE Long/MAX_VALUE))
I like Zach's intro here https://groups.google.com/forum/#!msg/clojure/d89gjX_5Om8/KgBcIORMGYYJ
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
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