Clojurians Log v2

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.

I was surprised at the cycle time for 18

Mine runs really slowly, not sure the best way to speed it up

I 'killed' outlets when they would end up in a pool.

like 100/sec

It's game-of-life like, it will stay at a repeating pattern pretty soon probably.

Spoiler from the kotlin slack, repeating pattern can take some time. https://streamable.com/2ud78

My day 17 https://github.com/pesterhazy/advent2018/blob/master/src/advent/puzzle17.clj

and my day 18 https://github.com/pesterhazy/advent2018/blob/master/src/advent/puzzle18.clj

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

kept me up all evening 🙂

@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 🙂

btw, my solution: https://git.sr.ht/%7Eihabunek/aoc2018/tree/master/clojure/src/aoc2018/day17.clj

Yeah, I agree; I didn’t have a chance to clean up day 17 to make it super readable.

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.

Same thing happens with English (or any other writing)

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

(if used consistently)

Yes, the right choice of names makes the code much more readily understanable.

A well chosen name is better than a long comment explaining something 🙂

yes, very true

and also very difficult 🙂

But I agree, my day 17 is quite opaque right now 🙂

there's only so much time available in a day

Gonna have to cancel today’s stream. I should be back tomorrow.

@ihabunek Peter Norvig always does that in his solutions (his PAIP book, Ipython notebooks etc) - always starts with "vocabulary" for the problem.

Cool, I'll have a look

Finding a vocabulary at the beginning requires a pretty good understanding of the problem space though

Which of course you don’t always have

@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

My day17 solution is too slow

adventofcode-clj-2018.day18> (time (part-2))
"Elapsed time: 29776.153121 msecs"
165376

How long it takes yours?

https://github.com/Average-user/adventofcode-clj-2018/blob/master/src/adventofcode_clj_2018/day18.clj

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.

https://github.com/bloat/aoc2018/blob/master/src/net/slothrop/aoc2018/day17-2.clj