This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (76)
- # announcements (6)
- # beginners (103)
- # boot (28)
- # calva (128)
- # cider (48)
- # cljs-dev (40)
- # clojure (268)
- # clojure-austin (2)
- # clojure-dev (2)
- # clojure-europe (47)
- # clojure-italy (10)
- # clojure-nl (17)
- # clojure-spec (2)
- # clojure-uk (15)
- # clojurescript (45)
- # code-reviews (14)
- # cursive (5)
- # data-science (2)
- # datascript (1)
- # datomic (52)
- # duct (4)
- # emacs (2)
- # figwheel (1)
- # figwheel-main (4)
- # fulcro (13)
- # hyperfiddle (51)
- # leiningen (19)
- # nrepl (40)
- # off-topic (45)
- # pathom (3)
- # pedestal (28)
- # portkey (7)
- # re-frame (25)
- # reagent (76)
- # reitit (7)
- # shadow-cljs (92)
- # slack-help (3)
- # specter (5)
- # timbre (2)
- # tools-deps (39)
- # unrepl (1)
- # vim (13)
@mfikes I almost went multimethods way exclusively to write this line, but then didn't https://github.com/mfikes/advent-of-code/blob/master/src/advent_2018/day_16.cljc#L54
I just looked at day 16 and it reminds me of a chapter in the reasoned schemer about Bitwise math
Seems like the difference between the register and immediate instructions would make it more difficult to model though
Since 'assembly simulations' are a recurring theme year over year, I've made myself a toolkit of techniques for creating a quick-'n'-dirty parser + interpreter. It's handy to know the pattern for things like that.
The way I think of it is to use a uniform function signature: given an 'address' and a set of registers, return a value. Then I have one function -
immediate - that just uses the 'address' as a value and ignores the registers, and another -
register - that uses the 'address' to retrieve a value from the registers.
Yeah, I don't golf my solutions. I prefer verbose but comprehensible, I can always refactor later.
I’d like to see a logic program for this one too, but I kinda doubt it’d be any more concise/obvious than e.g. mfikes’ solution
maybe b/c a purpose-built constraint solver for a particular problem is easier than describing the constraints in a more general solver
16 lvars binding op-code to operation, such that no counter-examples for that binding exist? Seems it'd be straightforward if all you needed in your database is a suite of counterexamples
The idea of logic programming is to describe what you want, not how you will get what you want. So ideally it would be more obvious, but not necessarily more concise
For example, in the chapters on bitwise math in the reasoned schemer, it takes quite a bit of work to setup all the prerequisite relational goals
Well, I was going to check out https://github.com/lambdaaisland/trikl based on an earlier recommendation of it a few days ago, but it’s not on clojars … 😞
I’m not sure, but it’s disappointing that the only way to consume a project would be deps.edn.
I’ve run into a few broken things in react-blessed in the past that put me off of it 😕
I think someone posted that too. I’m not in cljs for on the aoc stuff, which is where I wanted to try this. But, I think I’m going to try and find a way to try this at work for some tooling, since on most days I write more js than clj. (and we’re trying to find some places to re-introduce cljs)
Yes, there’s many things I could do to work around the unfortunate decision, but none of them are very satisfying.
day 17, no transients, no deqs.
"Elapsed time: 150.130027 msecs" "Elapsed time: 115.159781 msecs"
Hey! People who are learning clojure and doing AoC! Last week I did a code review on stream, and I found it to be a fun and interesting exercise. https://www.twitch.tv/videos/349004355?t=55m30s If anyone wants me to do the same for their AoC code, please let me know! I won’t do one every day (and I won’t do one today), but I’d like to do one a couple times a week if enough submissions roll in.
150ms has me beat by … a lot. I’m doing one point per iteration and I’m running in 8min total. Besides filling more than one point per iteration, I’ll have to do a performance pass this morning for sure…
1 iteration is 1 Y step for me, after which you either backtrack to Y-1 (no outlets in one of the puddles), or descent to Y+1 (all puddles have at least 1 outlet)
there is a bit of waist, when, say, out of 5 puddles only 1 has no outlet, so next (backtrack) iteration you scan all 5 of those for outlets again (against new "walls" updated with settled water). But that's like 2 incs and 2 lookups per puddle, which is essentially 0
These are the scores for Advent of CLJC so far. Note that I only implemented the scoring a few days ago, so I have to re-run a lot of solutions to be able to register a score. I might get to that in a couple of days. https://gist.github.com/borkdude/d7f42d4110e8a330d1d70f9242b14496
My answer is too high: https://github.com/pesterhazy/advent2018/blob/master/src/advent/puzzle17.clj#L51
The spring is at
x=500, y=0. I'm not sure it matters but it looks like you might have the x and y values flipped? I see that your ordered-pairs are
[y x], so that's fine, but I also see
(visit [puzzle-min-y 500] :down) which doesn't seem right.
I guess it's possible that the whole tree-walking approach is flawed and only happens to work on the small sample
I considered doing some kind of tree-walking thing until I realized that it's actually a DAG not a tree. Two outlets can fill up the same pond, so they need to know about each other.
yeah I discovered that as well but thought if I remember whether the square was settled or not, I can re-use that information: https://github.com/pesterhazy/advent2018/blob/master/src/advent/puzzle17.clj#L105
I wish I could help more, but it's really difficult to tell what you're doing inside
visit. It would help to break it down into steps and pull a bunch of that code out into smaller functions.
This person has an (even more) imperative solution, with a similar approach to mine: https://www.reddit.com/r/adventofcode/comments/a6wpup/2018_day_17_solutions/ebyq6mj/
Any tips for tracking down a stack overflow on
LazySeq realization? I get to a depth of around
y=800 before my algorithm dies.
Try to use recur, https://clojuredocs.org/clojure.core/recur the extra calls are re-used so don't add up to the stack.
Haven't tracked down the line of code yet. The stack trace gives me an endless sequence of
[clojure.core$seq__5124 invokeStatic "core.clj" 137] [clojure.core$concat$fn__5215 invoke "core.clj" 717] [clojure.lang.LazySeq sval "LazySeq.java" 40] [clojure.lang.LazySeq seq "LazySeq.java" 49] [clojure.lang.RT seq "RT.java" 528]
have you created any lazy seqs yourself? or just using via built-in e.g. map, iterate etc.
I am doing
merge-with concat in several places to merge some maps. Since I see
concat in the stacktrace I am suspicious of those.