This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (62)
- # aws (5)
- # beginners (59)
- # calva (63)
- # cider (26)
- # cljdoc (1)
- # cljsrn (22)
- # clojure (99)
- # clojure-austin (1)
- # clojure-dev (19)
- # clojure-europe (4)
- # clojure-hamburg (2)
- # clojure-italy (3)
- # clojure-nl (23)
- # clojure-spec (2)
- # clojure-uk (85)
- # clojurescript (41)
- # core-async (17)
- # cursive (20)
- # data-science (11)
- # datascript (2)
- # datomic (31)
- # emacs (7)
- # figwheel (28)
- # figwheel-main (12)
- # graphql (2)
- # hyperfiddle (3)
- # juxt (1)
- # kaocha (2)
- # leiningen (5)
- # nrepl (13)
- # off-topic (45)
- # pathom (13)
- # pedestal (11)
- # re-frame (20)
- # reagent (10)
- # shadow-cljs (92)
- # spacemacs (9)
- # sql (39)
- # tools-deps (32)
- # unrepl (3)
It took me the better part of the afternoon to notice that some of my outlets were getting duplicated, leading to
O(2^n) runtime as the depth increased. I never tracked down the exact source of the duplicates, but I suspect it was related to multiple outlets feeding into the same pond. I took the lazy way out and turned my outlets data structure into a set.
I think this is where my stack overflow came from, when I tried to concat some monstrously large lists of outlets.
Finally working though! https://github.com/bgrabow/advent-of-cljc/blob/master/src/aoc/y2018/d17/bgrabow.cljc
@pesterhazy It’s probably a bit late, and maybe hard to implement with all that mutability, but if you can dump out your world state visually, it ought to be (relatively) clear where the problem is. Almost all my problems came from incorrectly deciding flow/rest, and it was usually easy to see exactly which squares were being decided incorrectly.
If mine runs for 13s to give me the 100 entries after dropping 1000, ist that then slower than yours?
Spoiler from the kotlin slack, repeating pattern can take some time. https://streamable.com/2ud78
Mine was at ~500 steps, it pays off not to make assumptions about how early the cycle starts 😞
Day 18 was a breeze, but 17 I felt was horrible to implement in anything resembling idiomatic Clojure
I ended up porting a Python based solution to Clojure (that is, Java with Clojure syntax)
finally a relatively easy one. 🙂 went with elixir today, but if anyone wants to take a peek: https://git.sr.ht/~ihabunek/aoc2018/tree/master/elixir/lib/day18.exs
A little late, but Day 17: https://github.com/mfikes/advent-of-code/blob/master/src/advent_2018/day_17.cljc Note, to run this, I had to increase the stack size in the JVM.
@mfikes nice, you managed a purely functional solution for a problem lending itself to imperative solutions
on the jvm btw the imperative (but still recursive) solution I posted doesn't blow the stack
@pesterhazy Yes. If curious, I initially had it doing the spill left and right and putting both of those results into a map. That wasn't working on the real problem because it would branch out recursively too much (much like a naive Fibonacci), and wouldn't complete even if let run over night. The fix in this case was to take the results of spilling left and pass them into the function that spills right, eliminating the 2-way recursive aspect.
@mfikes yes this is very interesting to me given that I tried, and failed, for a few hours yesterday, before going with a super imperative approach
@mfikes I'm finding your solution a little difficult to follow, since it's quite dense with logic, how well are you able to parse your own code e.g. an year from now?
i tend to break things into smaller functions and write some docs, for myself if noone else 🙂
ah, it's always a matter of available time, and AoC is not too high priority for most people
i enjoy reading your solutions, since i usually pick up some tricks i haven't thought of
My opinion: The initial code you write is often not quickly grokkable because it is simply messy. Once you clean up the mess, it is still not quickly grokkable because it is using way to many words to say what it is saying. If you then golf it a little, you can improve understanding by using fewer bigger words to convey your idea. The balance is to not golf it too much were it becomes opaque. There is some sweet spot between overly verbose and overly golfed where I find code most readily consuable.
for more complicated problems i almost want to start the solution with a dictionary - explain what words mean in the context of the problem, for this one, i used "spring", "water", "flow" which are not exact but could be defined, and that would make the program easier to read
@ihabunek Peter Norvig always does that in his solutions (his PAIP book, Ipython notebooks etc) - always starts with "vocabulary" for the problem.
Finding a vocabulary at the beginning requires a pretty good understanding of the problem space though
@pesterhazy Yeah that's a fair point - I think that's part of why it helps though... You have a chance to loosely sketch out the problem before starting to code it, and in some cases that can save you some trouble down the line.
Everyone is different though, for me I can't start typing until I have my idea initially thought out, usually on paper
adventofcode-clj-2018.day18> (time (part-2)) "Elapsed time: 29776.153121 msecs" 165376
oh, I see you probably meant 18:
Loading src/adventofcode/2018/day18.clj... "Elapsed time: 197.051339 msecs" "Elapsed time: 6098.122681 msecs" Loaded
Just finished 17 - took ages, had to make too attempts. Annoyingly my first attempt was looking very close to being right, so I stuck with it for ages before bailing out and trying a new approach.
Definitely recommend taking the time to do a visualisation for these sorts of things. There's no way I would have spotted my bugs without drawing the pictures.