| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Phew. Nice that the puzzles for the 24th have been pretty easy
|
|
|
|
|
|
|
|
|
|
|
|
Back from Christmas travels, let's see if I can finish the set before
new year!
|
|
|
|
(Forgot to commit earlier, doh!)
|
|
|
|
|
|
|
|
Phew. Nice easy one for today! Caught up now.
|
|
|
|
|
|
It produces *a* result for each blueprint, but not the best result.
I feel like that's a hard problem. The number of decisions about what to
build when over 24 iterations explodes so much that you can't
brute-force the optimal geode count.
Either there's a way of pruning possibilities that I've not thought of,
or there's a pretty good heuristic you can get from the blueprint about
the proportions of how many of each type of material you want to be
producing, that you can pick what to build and get a geode count that
doesn't deviate from optimal in only 24 iterations.
One other possibility is transforming this puzzle into a SAT format and
letting a SAT solver attack it, with its ability to prune decision trees
effectively. But I don't have any actual experience with those, and I'm
not sure I have time to figure that out for AoC.
https://en.wikipedia.org/wiki/SAT_solver
|
|
|
|
Wow, it's hard figuring out the interior of a space. Did it the brute
force way, which worked OK because the total volume was small enough.
After part 1, I was hoping to be able to catch up the day I'm behind.
That's not happening today. We'll see how tomorrow's challenge goes.
|
|
|
|
|
|
|
|
You probably want to pass `-c` to cheat, if you want the solution in
less than a day!
|
|
|
|
I'm at least a day behind now, unsure where to start looking for issues
with my code for day 13, and struggling to visualise how to guarantee an
optimal solve for day 16 pt 2.
Oh well
|
|
|
|
|
|
Only tried it with test data before, where we don't need the permutation
pruning system. If you enable it with live data, it prevents any
permutations from being skipped, so it takes forever.
|
|
|
|
That was a tough one. Still takes 2.5s on my hardware. Should be able to
multithread the permuation search at some point, if I want to.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Because we're storing the input lists *as a list*, when we compare
successive pairs of lists, we can't compare the list nodes themselves.
Instead, we compare the lists they point to.
Unfortunately, this doesn't change the answer we get. It does improve
runtime though!
|
|
Gets correct answer for test input, but wrong answer (5711) for main
input. The problem is, I don't know where it's going wrong, and the
inputs are complicated, so tracking down the source of the problem is
going to be a major pain.
Wish I hadn't put this off for most of the day, and had more time to
look at it now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The trick is that we don't care about how much worry there is, we only
care how much worry modulo the test divisor, to figure out which monkey
gets the item next.
Now, I know that addition is stable under modulo arithmetic, but I seem
to remember that multiplication is stable under modulo arithmetic also?
(I think public key cryptography relies on this?)
So, by only keeping track of our worry, modulo the product of all the
test divisors, everything should still work correctly?
At least, that's what I tried, and it stopped all the overflow, and I
seemed to get the right numbers according to the expected test results,
and my final answer was also accepted. So I guess it does work
correctly!
|
|
|
