What are you coding?

Not Games
502

Day 20

We are recycling a bit.

As with day 19, I found part 1 more fun than part 2. I got to build lots of custom data structures, and then do a bfs queue to move all the pulses around and set input states.

For part 2, I took a punt and looked at the network layout. Specifically, the thing that feeds rx is a Conjunction module, so I look for cycles in the things that feed it. I count cycles between instances of the high pulse being sent to each input of that upstream Conjunction, assume those cycle lengths are stable (the same optimisation as the very similar problem in day 8), and lcm the lengths together. (Thus taking about 1 second to run rather than several hundred years.)

503

I just finished Day 19… I thought the final fix was going to be more complicated but it turned out I just had to set the opposite boundary in the previously processed piece of the puzzle.

solution here
(if i only post the link it always downloads stuff… or previews and I don’t want that)

I’ve been enjoying the feedback I’ve been getting on Mastodon and the clues. It’s quite friendly and far less overrun than the subreddit.

Might read Day 20 now. But we still need to straighten the Xmas Tree and I need more sleep. I already took a 2 hour nap this afternoon and it wasn’t enough.

1 Like
504

day 19

I really enjoyed the aesthetics of that loop of “start with a set of ranges, carve off a set that matches the condition, continue with what’s left”.

1 Like
505

there is a lot of xmas in day 19 … at least in my code. I like to use chars this year a lot.

1 Like
506

Day 21

This one irked me.

Part 1, again good fun. Rather than BFS as I’m clearly intended to, I found a way to abuse Dijkstra, fill the whole grid, and just count off the results.

Part 2, there’s a particular characteristic of the live data which does not occur in the test data. So the test setup is basically useless for verifying your solution. Get to wrong answer number 4, and it doesn’t even tell you too high / too low any more.

Nice geometrical insight though.

(The real problem was off-by-one errors in my code, but when they’re early enough in the series of equations they get magnified a lot.)

507

lagging behind now because of a few busy days after work was over and “vacation time” began…

in any case, day 20 is the worst so far. so fiddly. It took me 3 attempts to grok the basic demands from the text and I still don’t quite understand the result that is demanded. this has to be one of the worst puzzles in the 2 years I have done this. (I’ll get it eventually but it’s a real mess to implement)

1 Like
508

19, 20 and 21 have been the biggest slogs for me.

Day 22

Ah, that was a bit more fun. Not just another “now do it with a hyoooge number” part 2, but a genuinely different approach to the data.

Dropping from day 11 (but I did it better this time with a Z-sort and then a drop as far as it’ll go, rather than cycling a one-step drop across the whole grid). Ranges from day 5. Custom structs. A BFS queue.

Top 5 scores for “did part 1 but didn’t do part 2”:

21: 52%
12: 33%
5: 28%
19: 27%
10: 26%

509

I got part one of day 20 after writing some unit tests… this is mostly a parsing problem.
and I fixed my initial small bug in part 2 and then I think after 10 seconds when my laptop started huffing and chuffing I decided that I am not doing this.

edit: I have an idea what I am supposed to do. the thing in question is what I decided to call an Endpoint and its predecssor is a conjunction with four inputs (that piece of shitty parsing cost me hours, really having to take a 2nd pass over the input is annoying) and they are probably each on a cycle that needs to synchronize and we’re back to whatever day that was with the smallest common multiple… and my code is not really keen on tracking four different cycles

1 Like
510

(non-spoilery for yashima, spoilery if you haven’t done day 20)

What exactly do you need to track? Because if you can just shove that into a high-level-accessible variable from way down deep in the processing loop where it happens…

Also: I’m glad I picked this year to learn a parser library. I mean, I’m still wrestling with it a bit, but I can be completely sure I have a working parser by the time I tackle the actual problem. (And if I change the data structure I’m using, I change the processing of the parser output rather than the whole parse section.)

1 Like
511

I am a bit lazy I think–on the other hand reading the next day it’s more like "do I really want to try and understand a fresh problem or tackle one I at least know how to do? If my hunch for 20.2 is right, I need to track when the four inputs for the final conjunction send the HIGH pulse (it’s high right?), and since they haven’t synchronized within the first few hundred “Nopes” (each 10k button presses I output “Nope”), I am assuming it’s another one of those “we need a short hand” and the only thing I can think of is a cycle which I would need to track. and I sooo dislike the cycle detection stuff. But I guess it’s that or doing some “step counting” for day 21. maybe I should check day 22 :slight_smile:

I haven’t really had much downtime these last couple of days… all is prepped now though and tomorrow I have a day off from stress I hope.

and re day 20 parsing issues: today needed a second pass over the data after parsing at least how I structured it, to ensure all the conjunction stuff was tracked properly–my data structure was probably just giving me issues here.

1 Like
512

I went with 21.1 and that was … one of my fastest solutions ever to program I think. Also short code. If I had not forgot to add nodes to “visited” I’d have been writing this down as fast as I can type :slight_smile:

and of course part 2 is … ouch.

1 Like
513

21.2 is… hmm. In a non-spoilery way, there are some important characteristics of the full input that are not present in the test data. Which makes it easier (possible) to solve, but left a bad taste in my mouth.

514
Do you mean this:

image

(I only now thought of visualizing)

I’ve been trying to do coordinates with modulo for the endless version.
But haven’t been able to a) make it run beyond 100 steps properly and also getting slightly off numbers that suggest a minor misconception. But as the speed sucks that can’t be it.

515
Yes, and

the open line from start point to edge in every direction.

number of steps % grid width in cells is an interesting number.

1 Like
516

21.2: even playing around with the steps I take and watching what happens… even analyzing the numbers … and seeing correlations. I think that’s more math than I can get into my head right now. maybe also not when I have had more sleep… …

I think I will first try the part 2 of the flipflops tomorrow as I am reasonably sure I know how that goes.

then I might try to visualize 22.1 and maybe by the time I have not understood auf 22 works, I am ready to slink back and try 21.2 again. maybe some inspiration hits me. or maybe not.

I won’t have much time for coding during the next few days anyway. So it might just end here for me.

1 Like
517

Somehow after I had … given up … I managed to solve 22.1 and 22.2 today. Part two made my brain hurt for a moment, but on the 3rd attempt to grapple the Stackoverflow from the recursion I figured it out.
I think I might try the last few puzzles after all.

23 doesn’t look so hard… or maybe it is and I just don’t know yet.

Unfinished attempts:

  • 12.2 because there has to be something better than memoization libraries to speed up the brute force attack.
  • 20.2 because I can see some of what is happening but I am not sucessfully finding the cycles because during each putton press that final conjunction is triggered at different pulses and maybe… I need to find the one where the order of triggers is right… huh… there might be an idea here. Or not.
  • 21.2 because I am too lazy to do the math and calculate that “wannabe circle”. In theory I know most of what I would have to do and I just don’t want to write the code. It feels like dozens of chances for off-by-one errors

Merry coding :slight_smile:
This year was fun. I will do it again next year.

1 Like
518

I had a distracting and tiring day yesterday so I’ve stopped at 22 for now, but will return to them as I recover.

12.2 all the working code I’ve seen has used memoisation in some form
There’s a trick to 20.2.
21.2 is the one I liked least in an aesthetic sense.

1 Like
519

I’m back! Day 23:

Well, I quite enjoyed part 1.

Thought about winnow parsing, but just colecting the chars into a grid structure was fine. Slightly unusual search constraint but a BFS worked all right. Done.

Then part 2 came along, and the BFS doesn’t work as well when there are possible optional loops. This time I built Coord and Pathgrid structs containing valid nodes (still no winnow, just the lovely match_indices. And a multi-pass approach:

  1. Find “intersections”, defined as path points with at least 3 exits.

  2. Group those intersections, i.e. find pairs which can be visited without going through any other intersection in between. (And since my BFS here is gives directional results, set up reverse paths too. Yeah, should have put this part under the next point.)

  3. Evaluate maximum path costs between each pair of intersections. Lots more BFSes, each one basically part 1 in miniature.

  4. Use the network of intersections in a final BFS to generate the most expensive path from start to goal.

520

Day 24

Part 1 was a basic intersecting lines problem, with the small additional constraint of the intersection needing to happen at time > 0. Fair enough, quite fun.

Then came part 2 and while I remember doing all this algebra at school it’s pretty rusty, so I rather lost enthusiasm. Thanks to cideM for the gaussian elimination code at https://github.com/cideM/aoc2023/blob/main/d24/main.lua which I reused more or less wholesale.

Day 25

Well this was a bit perverse, because I don’t really count it as a solution in Rust. Instead, I converted each dataset into GraphViz format (via program a, but it’s pretty trivial), then ran it through neato, one of the many ways of getting a graph that’s arranged automatically.

Looking at the output, it was very easy to see where the links should be cut.

Then program b, which hard-codes the link cuts (the line in the published code is for the test dataset), builds a map out of the input and traverses it from an arbitrary node to see how many nodes are left in its partition—combine with total map size to get the answer.

And done!

2 Likes
521

Congratz. I’ll take some time for coding tomorrow I think.

1 Like