What are you coding?

Not Games
442

My day 8:

Part 1 was basically trivial so I had plenty of time to wonder why I couldn’t winnow-parse with repeat(). Some day.

Part 2: first step was a cycle detector (at each Z-node, store node, position in instruction list, and total steps, and exit if I’ve seen that (node, position) tuple before). Listed those, and oh look, I’ve got exactly two entries in each cycle, and they’re the same period. So incremental LCM it is.

If I’d been thinking slightly straighter I’d have converted those node IDs to integers from base 36 and not had to do all the slow string copying.

1 Like
443

My day 9:

Yeah, mine similarly (I built a rather neat recursive function). I’m a bit shocked, because usually the weekend puzzles are meant to be on the tougher side.

Now I’m only two behind, which I didn’t expect.

444

Day 8.2: After I had primefactored the cycles I realized that the cycle had to have the length of the command sequence-1 (or so) as a prime factor or the cycle wouldnt start at 0. In my case that was 271 :slight_smile:

Day 9 was quite the simple thing. I was also a bit surprised how easy that was.

I just finished Day 11 and I must say from what I read this morning I thought I would be in more trouble with this.

But my Matrix class was already able to extract coordinates for all the stars in single method call and I already had the distance function written into my coordinates from last year.

So really what I needed was to detect empty space… and calculate which ones would have to be added to each measurement. Part 2 was just a minor twist on that.

1 Like
445

Day 11

I did part 1 with the Manhattan distance method and sparse object tracking.

Part 2 didn’t pose a serious challenge as a result of the approach I did for part 1. I’m worried the simplicity of these recent days (and of the challenges so far…) is merely temporary. I think I washed out last year on Day 17 (which I still haven’t gone back to… I really should).

1 Like
446

My last attempted puzzle was Day23 last year and I never managed to solve that weird cube thing with the folding… part 1 yes, part 2 no.

The difficulty this year was a bit all over the place but I am also finding stuff easier because I did similar things last year. So I am hoping that I get a few more days–especially during the week–where I need an hour total to solve the problem.

1 Like
447

My day 10

Well, that got quite chunky. Most of my part 1 effort went into building some good data structures (TIL about the bitflags crate). Each cell gets a u8 of possible directions.

I know BFS by now. Look for a valid entry from the previous exit, bail out of it wasn’t there, store depth, go off in all possible remaining directions. Done.

For part 2 I doubled the grid coordinates and then wrote some more code to fill in the interstices (e.g. if x, y has no east and x+1, y has no west, then x+½, y is an open space). Then flood fill (BFS again, in effect) from the edge.

If I’d been feeling cleverer I’d have tied down the actual exits of the start point, and done winding rule or something like that.

1 Like
448

Day 12

I’m sad at how long it took me to complete Part 1. And sadder that the way to optimize to solve Part 2 hasn’t occurred to me yet – analytically or otherwise.

1 Like
449

I am still stumped about day 12.
Sitting here for hours and I had this brilliant idea to solve all with regex. but either I am making idiotic mistakes or there are multiple regex for the same configuration (the latter I assume which kinds of includes the first) and now I am back to almost square one having only eliminated the lines (118/1000 in prod) with a single configuration.

Meh.

There is obviously some elegant solution, but I have refused to look at mastodon et al to see what people do and I noticed last year that I don’t know my math and algorithms. I am just a software dev who rarely writes code at all.

1 Like
450

I think I have to give up for today. It is past midnight… way past. I have to work tomorrow and it’s a long day. I don’t know how to put what I would do as a human into an algorithm.

My approach was slow–almost brute force. Took 2 minutes. I wrote unit tests and the test input worked. But the result was still wrong. I don’t know how wrong… but wrong.

2 Likes
451

Day 11 can’t sleep AoC will get me

I thought all that “expand the universe” talk smelled bad, so like you two I took the approach of “add N when we cross a row” rather than “insert N extra rows”, and made part 2 relatively trivial.

Sounds as though 12 will be more of a challenge.

2 Likes
452

Laziness can pay off :slight_smile:

I have started on 13. And have some idea how to do 12 part 1 now. But no time.

2 Likes
453

Day 12 Part 2

I’m still not satisfied with my approach, but after rewriting to use some standard library stuff instead of trying to do memoization myself, I was able to get the correct answer in around 3 seconds.

On to Day 13…

454

Day 12:
I have a part 1 answer but the working code is wildly slow. I have a better version which I’ll clearly need for part 2, but it’s not working.

Day 13:

Today’s Christmas ghost was Bounds Checking. After that part 1 was pretty straightforward. Then I had an inspiration for part 2: instead of bailing out at the first error when I’m testing a line, finish the test and count all the errors. Then the one with 1 error is the one I want.

2 Likes
455

Not advent of code related.

I took writing [host.host for host in hosts if host]
As a sign something needs some refactoring.

2 Likes
456

Awfully close to [ ho.ho for ho in hos if ho ]. You may be turning into the programmer form of Santa Clause.

2 Likes
457

Day 13

Part 1

Python’s pairwise + in-place slicing made this pretty easy

Part 2

While I thought this was really going to turn into another slog like yesterday, I also realized I could just count the differences for each of my iterations and just match the first instances where the differences were exactly 1.

2 Likes
458

I’ve got the beard and birthday. I lack the belly and jolly.

2 Likes
459

Python makes this easier than java I thought.
My code was awfully complex. And because yesterday sucked… thanks @pillbox i now have a really nice solution. Sometimes I overthink things and optimize too early.

2 Likes
460

Also thanks to another coding friend I now have a pretty simple albeit slow (6 seconds) solution to 12.1

I do hate DFS so much I never want to program it. I had to go back to Day19 from last year and copy the algorithm.

2 Likes
461
DFS vs BFS and how it relates to Day 12

I have typically preferred recursive functions which lend themselves to DFS. However, in most years of AoC, and already in this year, I’ve hit the default recursion limit in python, so I opted to approach Day 12, initially, with a BFS (in hindsight, it shouldn’t have warranted a fear of recursion limit… so… not sure what I was worried about other than not knowing what Part 2 would throw at me).

But doing the BFS approach I did (task queue; each child node is queued at the end and the task processing done from the beginning) really sucked for a number of reasons. I actually had to switch to DFS, first, because append time on my queue (standard python list) was bogging down, so I switched to right-handed stack (using python’s collections.deque and it’s popright())

I debated whether to do a full rewrite to process the data as binary integers (using a mask digit composed of where ?s were in the input) or staying with what I had but memoizing it.

I opted to go the memoization route because it seemed like less work than the complete rewrite, and I’ve never concerned myself with “groups of digits” when processing (int & mask) and wasn’t sure how to approach that (other than translating my existing logic into rshifts, working from the tail end of the grouping values, and micro-optimizations like checking for (evenness || 0) to ensure proper termination of groups, etc.)

So I bolted on my usual memoization logic into the existing object classes I already had made (using a very clever family-heredity system, I might add) and that worked great for the sample data, but I was getting off-by-one-magnified-by-thousands-through-memoization (somehow!?) issues when working on my actual input data.

So I just rewrote the whole thing with functools.cache on a static function; it worked 100% the first time and was significantly faster than my own memoization. Which makes me sad; if I were a real programmer, I’d be like, “Duh, don’t write your own functools.cache, use built-in libraries!”

I would like to return to my home-rolled memoization approach and figure out what was wrong; it’s entirely an issue with storing ‘zero’ memo hits – permutations that didn’t result in valid grouping; memoizing that it resulted in zero; if I disabled negative-result caching, it took thousands of times longer, but the results were correct (I think, I mean, I didn’t wait the, likely, 13 years it would take to finish). But at the end of the day, because the memoization was bolted onto a class that wasn’t designed for it… it… wasn’t ideal to start with.

2 Likes