Fork me on GitHub

no regrets


@mfikes I almost went multimethods way exclusively to write this line, but then didn't kappa


case is way more obvious, and no need for open system


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.


woah, verbosy


Yeah, I don't golf my solutions. I prefer verbose but comprehensible, I can always refactor later.


That macro in your solution is quite tight, though 🙂


that's mfikes' macro


Oop! You're right, thanks


For that 16 part2 I really would have liked to be using Prolog

☝️ 4

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


I was imagining most of the complexity being in writing goals for each operation


Though I also imagine you could “cheat” by using non-relational goals/predicates too


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 based on an earlier recommendation of it a few days ago, but it’s not on clojars … 😞


not on github either?


looks like all of lambdaisland is gone


I’m not sure, but it’s disappointing that the only way to consume a project would be deps.edn.


how do you do that if it’s not on github?


lol nm — the link you provided has a typo 😛


Oh - that’s odd. Not sure how that happened… 🙂


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)


you could clone it and install it locally


Yes, there’s many things I could do to work around the unfortunate decision, but none of them are very satisfying.


Day 17 - my code really shouldn’t be this slow…


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. 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.


it took me WAY too long to do todays task


you'll need to zoom out


not very tidy but i need to work/sleep


I'm stuck on day17 p1 - my code works on the sample but not the full input 😞

Ben Grabow19:12:39

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.


@UANMXF34G I'm starting from [0 500] now, which should be correct


I don't think that's it...


I guess it's possible that the whole tree-walking approach is flawed and only happens to work on the small sample

Ben Grabow20:12:02

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:


I can't figure out where the flaw in the reasoning is

Ben Grabow21:12:01

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:


but the logic is quite different


you're right that my visit function is a mess of course


I was wondering if it would be possible to implement day 15 with core.async

Ben Grabow22:12:57

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, the extra calls are re-used so don't add up to the stack.

Ben Grabow22:12:26

I am using recur everywhere, as far as I can tell.


what specific line of code is causing the overflow?

Ben Grabow22:12:48

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 "" 40]
               [clojure.lang.LazySeq seq "" 49]
               [clojure.lang.RT seq "" 528]


have you created any lazy seqs yourself? or just using via built-in e.g. map, iterate etc.

Ben Grabow22:12:30

Not rolling my own.

Ben Grabow22:12:08

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.


Never use concat with lazy-seq


it's a known footgun


I use into instead of concat wherever I can

Ben Grabow22:12:28

Well it's a lot slower with into instead of concat, so maybe that's a good sign :rolling_on_the_floor_laughing: