https://github.com/zogwarg/advent-of-code/blob/main/2023/jq/14-a.jq

#!/usr/bin/env jq -n -R -f

# Dish to grid
[ inputs / "" ]

# Tilt UP
| transpose                       # Transpose, for easier RE use
| map(                            #
  ("#" + add) | [                 # For each column,   replace '^' with '#'
    scan("#[O.]*") | [            # From '#' get empty spaces and 'O' rocks
      "#", scan("O"), scan("\\.") # Let gravity do it's work.
    ]                             #
  ] | add[1:]                     # Add groups back together
 )                                #
| transpose                       # Transpose back

# For each row, count  'O'  rocks
| map(add | [scan("O")] | length)

# Add total load on "N" beam
| [0] + reverse | to_entries
| map( .key * .value ) | add

Through glancing at someone else’s code, I was inspired to just try simulating the A problem beyond 64 steps and seeing the result.

Essentially it reaches a (bi stable?) steady state between two numbers, which makes sense- if you can only make single rook steps, then the reachable squares will alternate every cycle.

Don’t know if I’ll try solve this again tonight but mentally I have now understood the solution.

So my approach to AOC has always been to write a pure coding solution, which finally broke down here.

First, the solve:

I call the unrepeated garden map the “plot”. Each repetition of the plot I call a “grid”. Hope that isn’t confusing.

1. Looking at the input data, it is a grid of 131x131 squares with the starting position in the center at 66,66 (indexed from 1)
2. If you imagine a chessboard pattern over the whole area, on each step the possible reachable squares alternate colors.
3. Row 66 and col 66 are unimpeded by stones, as well as the edges of each grid. This means that:

• starting from the initial grid, it takes 66 steps to enter a new grid. You enter a new grid on all sides.
• a grid is always initially entered from the middle of an edge, either on one or two sides based on its position relative to the grids that are currently being considered.
• each grid is independent of every other grid, except for the step where it is entered.

To see why that last point is true, consider that in order for another grid A to influence an adjacent grid B beyond the moment the adjacent grid is entered, there must be a reachable point further from the midpoint of the edge on the edge of A. However, because the middle row and column are free from rocks, this is never the case. Any influence from A reaches B too late, i.e. reachable squares on B from A will be reachable sooner from just travelling from the entry point on B.

4. The number of steps is 131x100x2023 + 65.

So putting all this together, the way I got the answer was like this:

1. Simulate the whole area for 65 + (5*131) steps (more than necessary)
2. Print the number of reachable squares in the grid at 65 + 131n for n = 0-5
3. Using pen and paper, determine some coefficients for some of the numbers that come up, add everything up in a calculator, and type that answer into AOC.

So I guess the answer I arrived at was what I’d been thinking I should be doing this whole time: a mix of simulating some of the problem and a decent amount of pen and paper work to get the solution out, rather than just pure coding. Fun!

https://github.com/zogwarg/advent-of-code/blob/main/2023/jq/20-b.jq

Completed when waiting for the second leg of my Christmas holidays flight. (It was a long wait, can I blame jet-lag?).

Have a more compact implementation of LCM/GCD, something tells me it will come in handy In future editions. (I’ve also progressively been doing past years)

https://github.com/zogwarg/advent-of-code/commit/fef153411fe0bfe0e7d5f2d07da80bcaa18c952c

Oooh I should run my code without memoization. Or just add a cache hit count.

Also, kudos for working with polygon area from the start. I was too invested in reusing my code as discussed elsewhere, but I came around in the end.

a: Just copied what I did for 10 b. and applied it to work here. Had to fiddle with it to make it work, but it worked. I implemented a line-crossing counting algorithm. If you slice up the area into rows, you can tell if you are inside the area if you cross an odd number of lines that vertically cross that row.

b. Pretty much just changed the input parsing and ran the same algorithm. Thought that it might be too slow, but I put in some stopwatch ticks and found out that it should take about 5 minutes to run my a) algorithm to get the answer.

The actual time elapsed was 5m50s.

I miiiiight try make a faster version but my head is too fucked up to care right now, hence me letting the slow algorithm run.

The hardest part has finding the right dart ascii library to use (by default dart treats everything as UTF-16, which is horrible for this sort of thing) and the right data structure (linked hash map, which is a map that remembers insertion order.)

So, like many other problems from this year, this is one of those direct solution problems where there isn’t much of a neat trick to getting the answer. You just have to implement the algorithm they specify and hope you can do it correctly.

a) I used a regex to do some parsing because I haven’t looked at dart regex much and wanted to dip my toes a little.

I considered doing this “properly” with OO classes and subclasses for the different rules. I felt that it would be too difficult and just wrote something janky instead. In hindsight, this was probably the wrong choice, especially since grappling with all the nullable types I had in my single rule class became a little too complex for my melting brain (it is HOT in Australia right now; also my conjunctivae are infected from my sinus infection. So my current IQ is like down 40 IQ points from its normal value of probably -12)

b) There may have been a trick here to simplify the programming (not the processing). Again, I felt that directly implementing the specified algorithm was the only real way forward. In brief:

1. Start with an “open” set containing a part with 4 ranges from [1, 4001) and an “accepted” set that is empty.
2. Start at the workflow “in”
3. For each rule in the current workflow:

• If the rule accepts part of the ranges in the open set, remember those ranges in a closed set and remove them from the open set.
• Remove anything the rule rejects from the open set.
• If the rule redirects to a different workflow W, split off the applicable ranges and recurse at 3 with the current workflow as W.
• Keep in the open set anything the rule doesn’t consider.

Because this is AOC, I assumed that the input would be nice and wouldn’t have anything problematic like overlapping ranges, and I was right. I had a very stupid off by one error that took me a while to find as well.

part a: nothing to say here.

part b: Before diving into the discussion, I timed how long 1000 cycles takes to compute, and apparently, it would take 1643175 seconds or just over 19 days to compute 1 billion cycles naively. How fun!

So, how do you cut down that number? First, that number includes a sparse map representation, so you can tick that box off.

Second is intuiting that the result of performing a cycle is cyclical after a certain point. You can confirm this after you’ve debugged whatever implementation you have for performing cycles- run it a few times on the sample input and you’ll find that the result has a cycle length of 7 after the second interaction.

Once you’ve got that figured out, it’s a matter of implementing some kind of cycle detection and modular arithmetic to get the right answer without having to run 1000000000 cycles. For the record, mine took about 400 cycles to find the loop.

a. while you can brute force this one in time, one simple trick to make it faster is to treat the symbols as bits and interpret the grid as numbers. It then becomes a matter of locating the reflection point.

b. It’s not much of a difference to solve b. The trick here is that if you did the bit stuff I suggested above, you’d quickly realise that a smudge interpreted as a binary number is a power of two. Finding a smudge is equivalent to if the bitwise XOR of two numbers is a power of 2, which can be done with some bitwise magic.

A and B were roughly the same difficulty.

So in my first year in university, in my intro DSA class, we learned A*. Have I learned any other ways to search since? Not really. So I used A* here.

It took way longer than it should have to solve, which I blame on my ongoing illness. The main sticking point was that I implemented a class to represent the search state, and since I was going to use it as a key to a map, I implemented a hashcode for it. The rest of the A* code freely flowed from my brain (really the wikipedia pseudocode).

Cue like 40 mins plus of wondering how the test input was searching over millions of states, wondering if I’d fucked up the A* implementation, wondering if the problem was too big for A*, and wondering if it was finally time to take a days break from all the aoc nonsense.

Anyway at some point I realised I forgot to implement the corresponding equals method to my hashcode. Once I had that my code ran in seconds and everything was fine. This sickness is the worst!!!

Finally! a Dee Pee!!!

This problem was mainly testing:

• Are you a bad enough dude to formulate this DP correctly?
• Are you a bad enough dude to choose a good DP state storage schema?
• Is your computer a bad enough dude to store all the DP states if you choose a bad storage schema?

…which is true of all DP problems, honestly. So given you know and understand how to approach DP problems, this would be more an engineering issue than anything.

So, as I’ve been doing the AoC things, I’ve been creating small libraries of convenience functions to reuse, hopefully. This time, I reused some things I wrote for problem 10, which was vindicating.

a. was a fun coding exercise. Not much more to say.

b. I lucked out by making a recursive traversal function for a), which let me specify the entry and direction of where my traversal would start. Besides that, similar to a., this was a fun coding exercise. I was surprised that my code (which just ran the function from a) on every edge tile) It only took 2s to run; I thought I might need to memoize some of the results.

a: So, I’ve been in the habit of skipping the flavour text and glossing over the prompt. This time, it hurt me badly.

I read the problem as follows: for N galaxies, find N/2 pairings such that the sum of distances is minimal.

At this point, I was like, wow, the difficulty has ramped up. A DP? That will probably run out of memory with most approaches, requiring a BitSet. I dove in, eager to implement a janky data structure to solve this humdinger.

I wrote the whole damn thing. The bitset, the DP, everything. I ran the code, and WOAH, that number was much smaller than the sample answer. I reread the prompt and realised I had it all wrong.

It wasn’t all for naught, though. A lot of the convenience stuff I’d written was fine. Also, I implemented a sparse parser, which helped for b.

b: I was hoping they were asking for what I had accidentally implemented for a. My hopes were squandered.

Anyway, this was pretty trivial with a sparse representation of the galaxies.

In retrospect that would have been far better for runtime, my dist function ended up being a tad expensive.

I substituted the rows/columns, with multiplication by the expansion rate if they were all numbers. And then for each galaxy pair do a running sum by going “down” the “right” and adding the distance for each row and column crossed.

https://github.com/zogwarg/advent-of-code/blob/main/2023/jq/11-b.jq

transpose is nice to have in that approach.

I used a class this time because it looked like it might be helpful. I don’t think it turned out to be that useful. Still, you can see Dart’s interesting constructor and getter syntax on display.

Pretty straightforward, though I didn’t read the format correctly and had the destination/source data reversed. Oops! Luckily, my performance here will in no way affect my future career.

I didn’t read the prompt correctly, which tripped me up. Also, while my solution is correct, it assumes that the input could be trickier than what the problem threw at me. Specifically, the edge case I had in mind was a range of values split into many subintervals and needing to track those mappings. I threw in some print statements to discover that intervals were never split beyond two subintervals, which was disappointing. Oh well- being correct is the best feeling you can have if you are otherwise empty inside.

Other than processing the input in the form of intervals, I don’t think there were any notable tricks at play here, so this was more of an exercise in implementing code cleanly, which I struggle with.

#!/usr/bin/env jq -n -R -f

# Get LR instructions
( input / "" | map(if . == "L" then 0 else 1 end )) as $LR |
( $LR | length ) as $l |

# Make map {"AAA":["BBB","CCC"], ...}
(
  [
    inputs | select(.!= "") | [ scan("[A-Z]{3}") ] | {(.[0]): .[1:]}
  ] | add
) as $map |

# List primes for GCM test / factorization
[
  2, 3, 5, 7, 11, 13, 17, 19,
  23, 29, 31, 37, 41, 43, 47,
  53, 59, 61, 67, 71, 73, 79,
  83, 89, 97
] as $primes |

reduce (
  $map | keys[] | select(test("..A")) | { s: 0, i: 0, c: .} |

  # For each "..A" starting position
  # Produce visited [ "KEY", pos mod $l ], until loop is detected
  until (.i as $i | .[.c] // [] | contains([$i]);
    .s as $s | .i as $i | .c as $c        |
    $map[$c][$LR[$i]] as $next            | # Get next KEY
    .[$c] = (( .[$c] // [ $s ] ) + [$i] ) | # Append ( .s ≡ $l ) to array for KEY (first = .s non mod)
    .s = ( $s + 1 )  | .i = (.s % $l )    | # Update cursors, for next iteration
    .c = $next
  )
  | .[.c][0] as $start_loop_idx | (.s - $start_loop_idx) as $loop_size
  | [ to_entries[] | select(.key[-1:] == "Z") ]
  | if (
      length != 1                                           # Only one ..Z per loop
      or ( .[0].value[0] != $loop_size )                    # First ..Z idx = loop size
      or ( [ .[0].value[0] / $l ] | inside($primes) | not ) # loop_size = ( prime x $l )
      or ( .[0].value[0] / $l  > $l )                       # GCM(loop_sizes) = $l
    ) then "Input does not fit expected pattern" | halt_error else
      # Under these conditions, synched positions of ..Zs happen at:
      # LCM = Π(loop_size_i / GCM) * GCM

      # loop_size_i / GCM
      .[0].value[0] / $l
    end
) as $i (1; . * $i)

# Output LCM = first step where, all ghosts are on "..Z" nodes
| . * $l