Trying to brute-force the second part?
Very similar to day 23 of 2017
Day 20… Where to begin…
At room 0,0 with 4 optional doors?
If you print each step you can see a certain pattern. It could take very long for part 2 to complete if you don't change the program.
Quite enjoyed this one. Had to backtrack a bit once I realized I was parsing into a difficult-to-wrangle format.
That’s it!
Again, my solution is really slow… It seems to be making progress, but…
I couldn’t sleep until I figured this out, despite being too tired to actually think. Whenever I alternate, push [pos, pattern] for each alternation onto the search stack, which can cause a lot of duplicate work to be done. Adding in the cache check reversed the duplication, which really shouldn’t have been there. That probably makes no sense to anyone but me, but I at least I can let myself sleep 🙂
memoize + store set of visited rooms in each path:
"Elapsed time: 1402.048955 msecs"
"Elapsed time: 1255.330936 msecs"
good thing, it is a "tree", not a graph
Interesting, I didn't even check to see if any of the paths ever looped back on themselves
I don’t think tracking the visited rooms is sufficient - you have to know you haven’t been to the same room with the same remaining pattern to search
I'd recommend breaking the solution up into multiple stages.
Hmm. I had to cache/memoize a bit. That sped it up a lott, but It doesn’t feel like I should have needed to do that. Maybe it’ll be more obvious in the morning.
Argh! All examples of part one work with my solution but of course the big one doesn’t 🙈
had a different issue, massively misunderstood p2, and wasted like extra hour on it
Ah. I think I know what I did
(time (part-1))
"Elapsed time: 39457.156774 msecs"
3314
memoize it, @lucaspolymeris
Don't know what memoize could workhttps://paste.ofcode.org/iKWt9afh7cWZg5UtPWhXRq
If you analyze the code, the only function that takes real time is nodes-depth
(filter (complement seen)
(remove seen)
move
might be used many times with same args
I always forget remove
, but will just change readability, not performance I think. But thanks anyways
move
?
(defn move [dir [x y]]
if you have shared seen
- make it transient
ahh right. But the only function that uses move
is build-graph
. Which takes:
(time (count (build-graph (clean-input))))
"Elapsed time: 77.78829 msecs"
10000
I tracked seen
per branch, so could not make it transient, but my move
repetitive usage is noticable
(reduce conj seen front)
(reduce conj ds (map (constantly depth) front))
into
might speed these 2 up, since it does transient under the hood, if possible.I might try to update neighbors
, since I will never use one key more than once
so you are doing exhaustive search, and then - select?
not sure what you mean. nodes-length
returns the minimum distance between the root and every other node
into
doesn't change much btw
but you assign those distances to every known room first
well here is my day 20, is not that efficient but it is concise, I think https://github.com/Average-user/adventofcode-clj-2018/blob/master/src/adventofcode_clj_2018/day20.clj
I like how it came using some string manipulation and the reader:
(defn parse-input [input]
(-> input
(str/replace #"[\^]" "[")
(str/replace #"[\$]" "]")
(str/replace "|" " | ")
(read-string)))
[ENWWW (NEEE | SSE (EE | N))]
still working on actually processing that for the solution though
oops, left the regexes even though I no longer need them
@lucaspolymeris I don’t think yours works. Try “^N(E|)N(E|)N$”
or even “^N(E|)N”