part 2: i got a clue on mastodon that I want to try out… they said it was all just multiples. I think the example is really really bad because there is always a diff of 1 somewhere in there that makes it seem like there would be no empty space. or at least that is what I am now assuming and it makes a bit more sense. should then be easy to replicate with my “mirroring” logic.
And then I wasted time figuring out why I am getting 41 on the testinput for part 2 when it is supposed to be 34 while all the while my solution is already correct or at least I got my star. and comparing to code from a friend … I am doing nothing wrong either.
Are you verifying all the results are within the provided grid? Are you ensuring you aren’t counting a position more than once?
prod input works. I admit I am too lazy to debug more.
definitely not counting doubles. might be an issue with the input. who knows.
AoC day 6: I try putting a new obstacle everywhere that was on the visited path of part 1, rather than the whole grid, which might save a bit, but I stick every visited (position, direction) tuple in a set and interrogate that per step.
My additional optimization was to start walking just a step before that obstacle and that includes one possible error namely if this obstacle is on the previous path aka has been seen before in this walkthrough you never get there. I just placed obstacles for each step as it happened… but forgot to check if I had been in the place where the obstacle before which meant placing the obstacle there was not a possibility.
Yeah, all I did for part 1 was store grid locations, not location-direction tuples, and I was too lazy to rewrite that bit. Still only about 4s in Rust release-mode.
AoC day 7:
That was rather fun. Though I confess I stumbled a bit in implementing a priority order version first, rather than left to right.
Part 1 was obviously a job for a bitmask (each interstitial place holds either a * or a +), but for part 2 I used the excellent multi_cartesian_product
in itertools
, which seems built for situations like this. Then all that was needed was a reasonably effective concatentation function; even “0” should produce a ×10 for the first operand, because 12 || 0
would be 120.
For what it’s worth, my ||
function looked like this:
let mut pmul = 1;
loop {
pmul *= 10;
if pmul > terms[place + 1] {
break;
}
}
accumulator *= pmul;
accumulator += terms[place + 1];
I find I’m writing more and more infinite loops with an explicit break somewhere in them rather than using a while
or do...while
just at the moment.
AoC day 8
Yeah, that’s pretty much what I did too. Honestly I think the answer here comes mostly from parsing the grid right, in this case so that I get
{'0': [(8, 1), (5, 2), (7, 3), (4, 4)], 'A': [(6, 5), (8, 8), (9, 9)]}
for the test case rather than an actual list of lists or whatever.
I was rather surprised to see that my naïve approach of assuming dx and dy were coprime actually worked. I’d expected to see e.g. dx = 2, dy = 4, and so an offset of (1,2) would also qualify.
I’ve gone from four days behind to one, even though two of them were weekend problems. Think I should probably stop for the night. (I’ll come back to Everybody Codes when I’m up to date with AoC, or it’s over.)
I am terrible with edge cases this year.
I think I am far more stressed out than I realize. The new job is demanding a lot. My partner is stressed out and normally Advent is quiet time of the year for us and this year there are sooo many events.
In any case it took me far too long for Day 9 too realize for part 2 that there is the possibility that files could move backward because I am doing fancy functional streaming I forgot to include a check that makes sure that isn’t the case. I had solved this basically this afternoon… and was stumped by that.
What helped was that I began rewriting the code without functional stuff and that was easier to unit-test and writing a test-case showed me the problem. I am apparently better at writing tests than at writing code oO
I used the AI assistant to generate comments. It is really not bad. Just a few small edits later the comments are better than what I would have written on my own. (Which would mean: NONE)
I got added as a reviewer to a diff that is changing a bunch of regrexes (autocorrect wants to turn that into regrets. It’s not wrong.) because some flags they use have changed. Trying to find the ones that actually belong to my team, I found one called “magic mushroom detection “. It is 5000 lines long. I gather the detection is “if you understand this” you have eaten magic mushrooms”.
I still remember the four page SQL statement.
(For answering questions like “I want heated seats and cruise control, show me every car-model that offers those” over every car-model for sale new in the UK.)
Today is Dijkstra abuse day
I have previously written my own re-usable Dijkstra and some associated classes and I think I need to refactor this tonight to look better and remove it from my Dijkstra algorithm but for now some fiddling with that solved both parts without me running into stupid edge cases costing me hours! Yay for Day10
AoC day 9: looks as though I ran into the same problem as yashima which I’d have liked to have seen a test case for, but that’s life. Rust’s built-in Range
class is great for this.
Before even realizing what I was doing wrong yesterday, I had already included a calculation that set the start position of each block (I am doing weird object orientation functional mashups for java as much as I can do that will have strange limitations on what I can do) and so I ended up just comparing if the start position of the block the file would move to was smaller than the block the file was in…
As usual I had 95% of the solution and threw it out several times because I was missing an edge case. That I found it when writing unit tests speaks to the power of testing over “using my eyes”. Testing changes perspective in some very important ways.
I am already treating Advent of Code like software in a lot of ways. I should really actually also do it in terms of code quality measures and write more tests. Writing tests appears to cost time, when in truth it saves time. My partner often howls about the upfront cost of quality being an issue in many projects. “Writing tests costs us time we could be writing code” because the advantages gained by prevention are so hard to measure. Which holds true across many different domains not just software.
AoC day 10: Part 1 was obviously solvable by Dijkstra, but the crate I’m using only gives one shortest route and doesn’t have an option for all of them. So I wrote a DFS which worked first time and is probably what I should have done for part 1.
AoC
Day 9
I’m unhappy with both parts. Part1 I didn’t even bother doing an OO approach for since it was much easier to just hack it with lists. Part2 I switched to OO but just barely.
If I found myself thinking I would need this pattern for any future work I would do, I may have been willing to spend more time on it… but… hopefully I won’t be responsible for disk layout or defragmentation any time soon… because modern filesystems are way better than anything I’d have the patience for
Day 10
I didn’t even bother with anything close to formal-Dijkstra. Part1 was pretty close, really, but part2 ended up back in my wheelhouse of iterating on objects that represent sequences.
Maybe I’m just grumpy because I’m getting over a stomach flu that the kids gave me.
I also didn’t OO Day9.1 (0! Why are we counting parts from 1? no sane language starts counting at 1), arrays are so much easier. Insisting on OO for Day9.2 cost me a lot of time because I couldn’t see that stupid edge case.
Day 10.1 + 10.2 but it’s Dijkstra variants (edit: mastodon immediately let me know it’s BFS not Dijkstra but I am reusing the code so it is in my project) I have now added them to my permanent toolbox:
If nothing else, the aoc-cli
package has reinforced 1
and 2
over 0
and 1
. I have to say, I really appreciate having aoc s 1 <part 1 answer>
what is aoc-cli?