What are you coding?

And now I need to google whatever it was you said :wink:
I’ve been a software dev for many years but devs aren’t necessarily coders…
I am not doing to badly with some of these problems but my theoretical side on math and algorithms is… lacking.

edit: Anyway I’ve prepped day 14 and I have begun some very basic stuff for 12.2. I am going out to the Christkindlmarkt tomorrow so I will need to push further coding shenanigans to the week-end.

2 Likes

I think you rapidly start to lose a bunch of the efficiency you gained by shifting to masks in the first place.

I was tempted to build a tester round very long bitfields, but I think this problem is big enough that you have to bail out early when a combination isn’t matching, and cut away that whole branch without evaluating it.

Day 14:

Part 1 fairly straightforward. Part 2, well, whenever I see a stupidly large number in AoC I know I won’t be iterating. Store each state we reach, stop iterating when we see one we’ve seen before, modulus.

I could have got cleverer on part 1 by sending a loose rock all the way to its resting point in one step, but [shrug].

1 Like

That is what I am still thinking because I have not yet found a solution. My attempt to cut off branches early has yielded very fast–albeit still erroneous results. Need to debug that tomorrow ff. (fortfolgende–german librarian speak for the next and everything that follows)

Day 14.2 I still need to mull over how to do right. Because I figured out a way to calculate stress on the dish without changing the base matrix… for part 1. Part 2… surely has a cycle somewhere but I don’t see how I can find it without changing the matrix…

2 Likes

Day 12

I ended up using someone else’s Python code to understand the algorithm better, and then translated that into Rust.

I did not use your optimisation for 14.1 which probably made 14.2 easier.

2 Likes

Day 15

A pretty clean one today; most of my time was spend wrestling with winnow, and failing to get it to do what I wanted. I think I need to put in some type annotations. Somewhere.

What i really wanted for #2 was a hashmap structure that would retain key ordering after updates - e.g. if I have keys 1, 2, 3 and then change the value at 2 I want it still to give me 1, 2, 3 afterwards. I could have got complicated with data structures but it was easier in the end just to search through the list.

2 Likes

Day 15 part 1 was very straightforward, so straightforward it did it in about 1 line and then extracted a method for readability.

Part 2 is … working for test input. But off by whatever amount for the personalized stuff. I did the same as @RogerBW considering the data structure. It screams of doing something fancy but in the end the basics seem to work smoother–except I am probably somehow missing some edge case that does not occur in the test input.

2 Likes

I find this a deeply frustrating state to get into. (A lot of my first attempt at 12 went similarly.)

2 Likes

I also still have 12.2 and 14.2 to solve. I have ideas for both but right now I am trying to do 14.2 and that is resisting as well, even though my unit tests suggest I am on the right track with the dish tilting.

edit: I think my matrix.transpose() operation must have an other coordinate mix-up that has not yet been relevant as it is very new
edit edit: yes, for the mirroring it was irrelevant if all the rows are mirrored… yikes.

edit edit edit: and now that I fixed the transpose… of course I need to have it go the other direction. because I am left handed probably.

2 Likes

I ended up writing four separate functions, one for each direction, with minor variations. Yeah, I know, nightmare to maintain, but for the brief period for which this code is relevant I can hold it all in my head.

2 Likes

I followed your clue and got to this line:

setTiltable( index, dir, dish, tilt( getTiltable( index, dir, dish ) ) );

got both 14.2 and 15.2 done now.

The issue with today’s second part was that I stored the buckets in a class variable which I know I shouldn’t and forgot to reset between test/prod. This is not the first time this happened either.

Now my only open is 12.2 which I will take a look at now.

2 Likes

Day 14

Part 1

So, I wrote most of this in the evening after my 3rd margarita and struggled a bit (I like to think it was because of the margaritas). Eventually, I figured out what I wanted to do, but 3-margarita-pillbox couldn’t be bothered to refactor.

So next-day-pillbox did and that worked out.

Part 2

Part 2 made me realize how I should have written Part 1 (again, going to blame 3 margaritas for this oversight) and I ended up with a much cleaner rewrite to complete Part 2 successfully.

But not before troubleshooting three different off-by-1 errors.
Very happy with my Part 2 approach. Not perfect, and I would done one thing in particular differently if I could be bothered, but otherwise a good day

2 Likes

Day 15

Part 1

I actually did this in a functional approach because I couldn’t predict what part 2 was going to throw at me.

Part 2

Like I suspected all along! Some sort of command sequence. OO approach as usual which was very straight-forward and undramatic.

2 Likes

Day 16 was almost as easy as Day 15 :slight_smile: Yay

My solutions keep showing up on my github of course :slight_smile:

The only real hickup was not realizing that there were going to be bouncing beams of light … but once I had realized that was the issue that was fixed quickly with the tools used on previous days.. Coordinate mixups are so expected these days… I wrote a unit test to debug that because it’s faster to write a boring test than to actually wrap my head around left/right/up/down

I do wonder how they order and classify problems and how they generated the input for the rolling stones puzzle…

With 15.2 I got a feeling that I was already being told how to solve the problem and all that was left was actually writing the code.

Day 16

Easy for a weekend! I mean, third Saturday in 2022 was that one with the Tetris rocks and the air jets.

A blocking border character rather than mucking about with if x > 0. A struct for coordinates. A match on characters. Making it into a function and scanning from each edge spot.

All my code’s visible on codeberg.

Here’s my very crude difficulty analysis of this year’s part 2s, based on the stats page.

12: 35%
5: 28%
10: 27%
1: 24%
14: 18%
8: 16%
13: 13%
3: 13%
4: 12%
15: 11%
16: 10%
7: 8%
11: 4%
2: 4%
6: 2%
9: 1%

The percentage is the proportion of people who have done part one, but not part two—there’s no public information available about the number of people who’ve tried and failed at a part one. (Number of people who’ve downloaded their puzzle input might be interesting to know.)

I’ll agree with 12, 5 and 10 as the hardest so far. 1 was hard for a day 1.

1 Like

Day 17: now that was a good meaty one.

In fact most of the meat was finding out how to use Rust’s pathfinding crate, which does Dijkstra and other things. The Position structure is (x, y, direction, straights), which informs the calculation of exits from a node, which is in a lovely successor function—which in turn meant it was all laid out ready for me to tweak in part 2.

Had to go unsafe because I wanted to be able to see my grid structure from way down deep in Position, which meant a mutable global variable. Feeling vaguely dirty now.

1 Like

Do you have a clue for me how to weight heatloss and instability when when implementing the pathfinding? It has to be that, right? The path is almost the one from the example… almost .

edit: also why is my code fast on the example but seems to take forever on the actual input? Isn’t A* supposed to be fast`?

1 Like

I thought about A* but couldn’t come up with a good heuristic so fell back on Dijkstra.

My code takes about 0.85 seconds for part 1 and 2.4 for part 2 on the 141-square full data set—that’s Rust in debug mode so basically no optimisations.

Hint: I have a four-variable path node structure. Two of them are X and Y, and those are the ones I check in the terminating condition.

1 Like

Here’s mine structure or as java now says “record”

record Crucible(Coordinates position, int heatLoss, Direction facing, int instability, Crucible previous) {}

For runtime purposes once I have the correct results from test input I plan to remove the path storage as we don’t need the path. For now I am still debugging. Dijkstra also seems to not be working for me. I am just too … empty-brained this week-end I think.

Weirdly the results for Dijkstra are way off, while my attempts at A* were “almost there”

What’s instability? Number of spaces moved in a straight line? If so, something very like that has worked for me.

sorry, instability was what I called the variable that counts until you have to turn. It seems to be needed for the distance calculationg.
I am still struggling.