advent_of_ruby 0.2.0 → 0.3.0

data/data/solutions/reddit/ruby/2019/16.yml

@@ -0,0 +1,59 @@
+---
+- :author: Kache
+  :url: https://www.reddit.com/r/adventofcode/comments/ebai4g/2019_day_16_solutions/fb3zrlr/
+  :body: |-
+    **Ruby**
+
+    [Part 1 and 2](https://github.com/Kache/advent_of_code/blob/8ee09f0889873dea5d4fde32ebcd160b5a2dd8b7/2019/solutions.rb#L599), about 10 lines each, runs in 2 secs & 4 secs, respectively
+  :replies:
+  - :author: craigontour
+    :url: https://www.reddit.com/r/adventofcode/comments/ebai4g/2019_day_16_solutions/fezx2c3/
+    :body: |-
+      > Ruby
+
+      Hi
+
+      Could you please explain how the following works in your solution (esp the reduce function):
+
+      ```ruby
+      nums[nth - 1] = (nth..nums.size).reduce(0) do |sum, n|
+        sum + nums[n - 1] * base_pat[(n / nth) % 4]
+      end.abs % 10
+      ```
+
+      Regards
+    :replies:
+    - :author: Kache
+      :url: https://www.reddit.com/r/adventofcode/comments/ebai4g/2019_day_16_solutions/ff2c8ir/
+      :body: |-
+        Unwrapping the `reduce`, the above is same as:
+
+        ```ruby
+        sum = 0
+        (nth..nums.size).each do |n|
+          sum = sum + nums[n - 1] * base_pat[(n / nth) % 4]
+        end
+        nums[nth - 1] = sum.abs % 10
+        ```
+      :replies:
+      - :author: craigontour
+        :url: https://www.reddit.com/r/adventofcode/comments/ebai4g/2019_day_16_solutions/ff39jff/
+        :body: Sorry, I was really after explanation of how reduce(0) works
+        :replies: []
+  - :author: petercooper
+    :url: https://www.reddit.com/r/adventofcode/comments/ebai4g/2019_day_16_solutions/fb4e57x/
+    :body: |-
+      Woop, Rubyists unite here in the comments :-)
+
+      I just finished and came looking to see what techniques people had used, and amazingly (reassuringly?) my part 2 solution is almost character for character the same as yours :-) (Except I used #length out of habit, and I only convert the relevant part of the input to integers.)
+
+      https://github.com/peterc/aoc2019solutions/blob/master/16b.rb
+
+      My part 1 is somewhat different to yours though as I used #cycle on a pre-constructed pattern array rather than doing it on the fly.
+
+      https://github.com/peterc/aoc2019solutions/blob/master/16.rb
+    :replies:
+    - :author: vinc686
+      :url: https://www.reddit.com/r/adventofcode/comments/ebai4g/2019_day_16_solutions/fb5105r/
+      :body: I couldn't finish part 2 in time today, I'm really impressed by both of you, my code is a mess by comparison!
+      :replies: []

data/data/solutions/reddit/ruby/2019/17.yml

@@ -0,0 +1,48 @@
+---
+- :author: p_tseng
+  :url: https://www.reddit.com/r/adventofcode/comments/ebr7dg/2019_day_17_solutions/fb73yzz/
+  :body: |-
+    I guess I'll throw my kinda weird solution out there, in the style of some of the weird solutions to day 13.
+
+    Thought process someone might go through to arrive at this:
+
+    - Ah, the instructions state that the robot will output a large number, then halt.
+    - Look for any addresses that are outputted right before a halt.
+    - What functions exist that modify those addresses?
+    - When those functions are called, what are their inputs?
+    - Probably the position of the robot, right?
+    - The robot only cares that it visited every location, right? It doesn't particularly care how it get to those locations. Straight path, winding path, it's all the same to the robot. So then what if it teleported, with no memory of how it got to where it is...?
+
+    So that's (Ruby) [17_set_and\_forget.rb](https://github.com/petertseng/adventofcode-rb-2019/blob/master/17_set_and_forget.rb)
+
+    I mostly wrote this code since I haven't properly written the code that breaks up the instruction list into three functions yet, so this is just to amuse me while I figure that out and write that...
+  :replies:
+  - :author: gedhrel
+    :url: https://www.reddit.com/r/adventofcode/comments/ebr7dg/2019_day_17_solutions/fb8xxx5/
+    :body: Yup. I've been reverse engineering the intcode each day after solving the puzzle. Some nice techniques there (including self-modifying code to manage array indexing).
+    :replies: []
+- :author: alienpirate5
+  :url: https://www.reddit.com/r/adventofcode/comments/ebr7dg/2019_day_17_solutions/fb6xeny/
+  :body: |-
+    Ruby: 524/311
+
+    Part 1: [here](https://topaz.github.io/paste/#XQAAAQAyBAAAAAAAAAARiEJHiiMzw3cPM/1Vl+2nyBa63n8Kt1xEsGKaC0+Fz4mBFJqbLuOp8Ux6B8b1flK0MINiN7e1CbqxYHulKoX7k0SdDzFZ3rFasBPAhw3mspjOaPLdvh7E+aHayLqhOs/ZizNBT2SSDm1cel+gjP1TicCUfZ+P48/STqF3MJ2Cmdpe6tce5K79pwVp2HFot7473ftoSZIGAPu/u4+TXiiaKmUBm6oapgxS4qcrU4G3XI4oC3HUWa2cCz6m6krJ6JIzj1qFulKZFpOx8j78BGaYjv8LF6t6pWsJqdPK8+OlyvK8fv4E5UpR0WpsujMS0VfiQ5hszsHmtVgMF1IQkjZJ5wBhuRtj/8OoPVnh8zNxVW2set5M/XIXdVaEcMYIg8khaAzISMxcC3AUrGCCXNtpjoCXezZ3C8MS9QVHdN0zLHRraOtIbddqmkS+y2KViHiKOYvqtxdGc23Aibjnevdy8tJRgjl7FxUDz+ZgYGlgo9KiogbDo/1gSjK5l6eKcSfUXGshNAd7dwLJ0cLrxveLnVhFSY2knKl/G2yA4zAQ6dxmgpT3lI2Fh8OmMVRGbHbogOBbIVb8bgbB4MiPxl3ulOItSuzhQo2laq994hWFAiO4D0c38hKAgAehMINCyZl6mSgFWEyb1MH65kHPWwiO2N351htN8oK5kGHA8yWJYkK1/nN9wtalBedzSxJppKGqs3k0W8bnEcq1EqLeq9wS7yJSVP/Jl2qW2/xhJ5GEuBK8qgyw0n/3/le3mg==)
+
+    Part 2: [here](https://topaz.github.io/paste/#XQAAAQBsBAAAAAAAAAARiEJHiiMzw3cPM/1Vl+2nyBa63n8Kt1xEsGKaC0+Fz4mBFJqbLuOp8Ux6B8b1flK0MINiN7e1CbqxYHulKoX7k0SdDzFZ3rFasBPAhw3mspjOaPLdvh7E+aHayLqhOs/ZizNBT2SSDm1cel+gjP1TicCUfZ+P48/STqF3MJ2Cmdpe6tce5K79pwVp2HFot7473ftoSZIGAPu/u4+TXiiaKmUBm6oapgxS4qcrU4G3XI4oC3HUWa2cCz6m6krJ6JIzj1qF40qv6DPnZ6jsRgzy58rLdU+H2GDg0ZWLKAEdp6xMK2K7YIEQWuBO2tuQgq9OgNCIQS9sCfTEW17T89wblZhz3vh1WtlxES5c7g0qD2h96H7/chNqsaqAXbZjlIg7rGrd+PkH6W6WIxe2AGz7YMSMCAvtwO5NSauiP+h2MrfX59Ibb6G117QkDDa9gBK+55eWDw1hZ1OBL/W+ZtK/g7BVwZTnu3ZkVcLc2Wc37PhYyIxoq30vqBbzVeFRJ7KunXj6HF8CtZMTgEDCErZR3ygm+ESpe1EQeDtXpRznUCWQ4Wa8U2KB85IxintMa8jhp2JgK75Ag3DxbkaqYeXZcGDVMYTfyvtj8fDf9O+YmrYIebER2OwwKhpLScf/xDQ3Ph2phgsoJTv+34wscTO3XrHhEn9JP+wl422VhHaXO1x5UwEFe3z5bslJf11pkScJK+wOoqIeT8EFxQkkayxYNBwAKNidS5+oifnXC3JOKcnQlmZJ+5+u26NsHLvGLkGric8m1cn/6vIKZg==)
+
+    libintcode: [here](https://topaz.github.io/paste/#XQAAAQDSDwAAAAAAAAAR4CRJKPo4y0sUUbMOOHiGH/+y1uugceRRc4OmINsbWz87fAbuuwbuylW+PKnj7cAeqQ4VP3PnSVnRx759Hwzb+4Z+5+EVb1El60Rl242NbBcYE0uVPyVEzd09utMDbapZLlzdEykmmN9u7FO4Wd157Hx4Kiwy5HeWs0zthXMZlNDkH/7uBa8RnKjBJDnr4W4rvLkf9tdmjWN24G1Q38voSe9nosTEUqP/s4z2Q/1BOSYnp0482YgrwbeQ5JEW6U07Ueic1wOFLZkd/F0w3rkZxhFqKSU+fZuav2WnY9a447f8XS7oFtV95GWD6aSaCqpK4RMjMngLGG3biXEIl1m4SvD9ld6ppzSQ+RuZqHh96qjjuRNix456qXHHGxN0vOxWaseP1zIByG+/UN8UE8wcjIZYGV05k3v2/Rqar2POaDQDHmKUCY61ZuQpWWDu5eK2dVD/+vzoeSzJptzOFdABxu5g8eLaWUpa1MPrs/rzKoO5SLM0LSbese6AX+sxqDIqAHrHW8tPSv68E3wDF/3V62hwuAHreNuvxLoPUyMnZAfEnC1NLNwfUXvEzwWrVMNMbCXeSpCsafCRZka8BWr+R1nBi3IreMSoJvhggRUs7o7zZQzASzXxfyfIQH+QpI0MXGnhLKX61uX1HnxNdyRp0nRyz14kd+LTYBTfWREPswUGvVKTPWDpA+7tmGPRvMkcOtJLG0aGjUN0qRXGFH8yT0qsQG/vRSwg0KHKQsEkqvKc5kW89aP2ds+hO5qmJMOwTQXP8dPlG1GKfy+++OFB3jOEKzywcDYJbhekbej+Dad0egXMElIuzgi3sdZ0uwOdZrxX8F1bnPxfL+K86yB/9O75UUN1g8JRL+5Mq8UC5bPanxeF3zf45K/pY0vzFxjSredt7lSdXdidFgglYG/hSN9LGrg3EQObJd6ID96+e+TubW2644KyaUqbp5tesXg6o/bwTSlE2l/dKkeutkH2Z3xKDFZijN7aVqb3rshi6wPAHWfN7i9Zpe+feACDvLzW9Siswlu/NBj7Z6obbEZyxm5GX0cB9VXTBK5+5ZdjvTLrRR6ZBBqrUQrEMX+V55rHxeIMYni/NKHud6AdPVWx5M6zNzs4FIU2Nc214zFzB/YEvR8jDmI0sQqjcB/RbsxonWCLAVCMG4eNAqRPrU740/bbsOUQyDFGP2tU0KR7nmufkOwANakFKLLCnIcB3HnxuvmjwIzMDp5ISo+NYs77eJkCLz3vGX+tPLnlG5MmndeCDHHOShoyegIvETBgl3QAdCUuPVtMcqKx3XdSVediE1M0xZ3F3ywKokPqIo20BTZ1OZ2T2A0EFLItDwa2jJcxS2TVPGGt/a2gU/8C3MhT4dn19wRYovGCerE9hdPAjv7MYOr416Auwpmq/EOo5zY9xR82FtOrHe+CdJ3wVrVjICsGQluXmYLaxvL561ORSvgdhtUlTU6FJ30ZniKrn90hfs6wuZ22e66rILi85TrmlUoemMeoC57EGAlzL59wTRJTpLvpSGwotkZmcQeicOoYlwIL8agrqGxDL6DiTyQ/PWboW8E0xGdUqsLosf6FSR/gWRYg+hH0fg0juQyKq0rbaHapOiE8RsI3LfX2JmoHaywbu/zaVZMKrHX74hSTzzSQyGnVjH5tgqDvbjTkY8UIGJe4QR2BuzE2+trAeSLUTBYJfvaQuJDJJSX3SmVhAMud5y2rije5jQcrqzXJCGJO1/af+YZm1dto9JXX46xL0xu1rL93rWStjEfEV1f7LFUs9eH9TcRsYGwICmqPkEiV7jOTpOqsDOeWLXpufrih0qc3dm5+PyrVc7gCXkq6d2cMb40qlf7c0tk=)
+
+    input: [here](https://topaz.github.io/paste/#XQAAAQAuEwAAAAAAAAAYiwLht+r38I0p+w2fBErV6JvUnsjbSeFdWbb2XDzkZMdraMQF7wPtKIHccwLk+C1K4HrCvyDKJVOqAUm+UagZp6D91IZ0NXbgEaStI4mGRflWbeMW1GwXLBltQ8L0COOEh1llERK5W/dcs2E2p9YHkrb3qIw/dVdpzZ7t2npOmXeK5O9Qyx4nS8+AZoK4Elp3uwpjbTaiH6/+aQHESvg93PXq+mSdGugKh5mDSTOqFHz9DQYafS52WvGYxlUxuIEm0YVd73/T3mC6PI0zMJTekNa50ao7DFPQhwrDlxoaQ0SSnWBTRFxv0O8sh1ipRxUhfv/7P7ZnUIZVnEva8+MUvNLY/Lt5ljoSldqWfzgaSJe4lmyKY1xsrUNDT8q+w6W5Jn6xB4itm1WqqXmvWdy4LtGK54E/G6X7ksbgf1ud/bwHKGHg0Q2Jo7SoKRs65r6hUiny/GNQhF1V67JXuwvn9l1/cbtVF+Dy534HSB8e0b3KEwgONUf21wSecZ8YhqmWMIlczUUBlQlBC9rCVoZxpY4sW3hmV+xMl6ufZqTeoWf258gZ+dkSOUgAu6bUTkSp7nyJh2q1RwFfgKpBqe5J1fg8e9X9V/Z8H3YJctq2DRTb5Gr8CTOLjmiAklg1wcR1rPhaXgrp08URgAX0eQ7jQn2soXHv6S+XJTJo5pMCYl8Uxp/siOvRZ0iMonCKwt7DPNBYON8fs49RJ0yOFIi5IQpI8o2Rz8OOQ3DdPhURUl1iCR9JH/bnk2iVMTNRalXceOfRgCOJkw8bWjWyMxRyETviHlcCnhfEBIg6i3t7uYdzBuSCwSgn1zYj2ccvfQJok4BcFhP3S4rOlJQrCX1WwduHxN0n5NURNo0wW0xEz6ororMdsexQDLdl0D7D7EiqrCgO2zuMzzYAH6Cxnc8bLay3AbIkQC2Tfo7MEI91JSPnqCTLhjZzBNMj8dRw0BYz89Jws0X6S8eYrlQxh2/hZo6w8W8sBUgo4tpG2heOxxZcPMb8azuMgMmq9rCLOkZHUnVRqgo1psrm5GkgZsmJhq/90iZgVMb7u3IL49TvuSf3xS+2HFNJmE/KqsahRN5OzlYyoj7pgvD563yFk2VmdbFo1d/lU11yl30E4rjWrdQZj2IHVvhFVeMtJZ8NkacbCtwsxJtOglLWJuaFBqeJQ8oHF9vIwnG+vND4wSHrUzlsJqXfxmsM918IkU61nwIfUH0cj3qKNnnQIzSkZrwgl8IZaZiYBPseby6fLWk3Px15gtb9cAMxdgMmhv4tSVu9aS/in2KkbAD/6pjLuDDvzBD2Hd0uR9jdm5nh9qI3S/PyVONF49WY19K9i7LGL59xLXaLKWY0g8+DI2UVMLdZszTThC/4yjsV2Nln9d/Q6sqLwMmp0XGvg5bkkQQaVw464lI2dmjNPCAxdk5ez9PDR/khIyNV2O2AxBw9Ilhjl4JDgBFvyzouUBNr0Oy2YNg04FqtMLH68lE2c7u+1J0zdyRTZUCLM2Y+ibqss5HxA1ozGsX7TBF62dC0ZLLQaH5C+KrPAP7ryy+8kYeuXalmXxsJRJPXc/2bB1ruFVIqK8Gvyax1zgGA3WxijzNvC+ti0tTE5Irw6sxsbPybYO7NwgQrX/hLNQ+dOtmK0lv76uDrS+pWaaUP+GYZW5g8b5ESz8eCg9i5hkzZ7PFoqzDl50H+Y3RkkBjFph5rp//O0pJm)
+
+    I solved part 2 manually. This one was fun
+
+    part 2 input:
+
+    ```ruby
+    A,B,A,B,C,C,B,A,B,C
+    L,8,R,12,R,12,R,10
+    R,10,R,12,R,10
+    L,10,R,10,L,6
+    y
+    ```
+  :replies: []

data/data/solutions/reddit/ruby/2019/18.yml

@@ -0,0 +1,25 @@
+---
+- :author: firetech_SE
+  :url: https://www.reddit.com/r/adventofcode/comments/ec8090/2019_day_18_solutions/fbb0sqh/
+  :body: |-
+    [Ruby, 641/396](https://github.com/firetech/advent-of-code/blob/master/2019/18/keymaze.rb)
+
+    I was quite stumped when I read the instructions this morning. I could understand them just fine, but I had no idea where to start implementing. I had to "cheat" a bit by looking for inspiration in some posted solutions. I'm mainly doing AoC to improve my algorithm skills, so I consider this part of the learning process (even though I obviously try to avoid it as much as possible).
+
+    Anyhow, I ended up with precomputing the paths between the keys (and from start to all keys) à la [/u/mcpower\_](https://www.reddit.com/r/adventofcode/comments/ec8090/2019_day_18_solutions/fb9wg35/) using a BFS from each key (and start), and then doing a recursive DFS (with cache) over reachable keys, somewhat inspired by [/u/sophiebits](https://www.reddit.com/r/adventofcode/comments/ec8090/2019_day_18_solutions/fb9w5oq/). This got the job done and I submitted my answers, but it was unsatisfyingly slow (both parts calculated in a total of ~35s on the Xeon E5420 server I usually use, and ~15s on an i7 4790 workstation). I tried optimizing back and forth but nothing really made any dent (except using JRuby to run it, which brought the times down to ~25s on the server and ~8s on the workstation)...
+
+    ...until I saw [/u/sim642's edit](https://www.reddit.com/r/adventofcode/comments/ec8090/2019_day_18_solutions/fba0o50/) and made my precomputing classify passed keys as a prerequisite, just like passed doors (it would be silly to walk past a key without activating it). This significantly reduced the amount of nodes the DFS had to traverse, and brought the runtime down to a reasonable value. It now takes less than a second per part when run with JRuby on the workstation:
+
+    ```ruby
+    $ time jruby keymaze.rb
+    Minimum steps (part 1): ████
+      (Parse: 0.430s, Calc: 0.377s, Total: 0.808s)
+    Minimum steps (part 2): ████
+      (Parse: 0.082s, Calc: 0.629s, Total: 0.711s)
+    jruby keymaze.rb 7,80s user 0,21s system 285% cpu 2,811 total
+    ```
+
+    ^"Parse" ^here ^illogically ^includes ^the ^path ^precomputation, ^btw.
+
+    I think I'm satisfied for today. :)
+  :replies: []

data/data/solutions/reddit/ruby/2019/19.yml

@@ -0,0 +1 @@
+--- []

data/data/solutions/reddit/ruby/2019/20.yml

@@ -0,0 +1,118 @@
+---
+- :author: firetech_SE
+  :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbhgxoo/
+  :body: |-
+    [Ruby, 1485/984](https://github.com/firetech/advent-of-code/blob/master/2019/20/donut.rb)
+
+    I woke up today, looked at the problem, understood it just fine but couldn't come up with a good way to parse the vertically oriented portals of the map, and just went back to bed. A few hours later, it dawned on me that I could just parse the horizontal portals, transpose the map and run the same parsing again. After some experimenting, transposing the input turned out to take basically no time, so I started implementing that. I'm mainly posting this because I was quite satisfied with the quirky simplicity of my parser. :)
+
+    For the actual traversing I initially just traversed the map from AA to ZZ using a big BFS that took portals into account (I generated a Hash dictionary of `[x,y] => [x,y]` for all portals in both directions for this). This worked just fine for part 1. With some modifications (modifying the portal Hash to `[x,y] => [x,y,level_delta]`, with `level_delta` being `1` for inner portals and `-1` for outer), it also did the work for part 2, albeit a bit slow (~6s total runtime on a Xeon E5420).
+
+    I did have some initial issues in part 2, finding a shorter path by moving to negative levels, but after blocking that and making sure `level_delta` was set correctly (it was initially, but I had mistakenly inverted it when looking for issues), I got the correct answer.
+
+    Later, I applied some knowledge and tactics from [day 18](https://www.reddit.com/r/adventofcode/comments/ec8090/2019_day_18_solutions/fbb0sqh/) and started precomputing all the paths between portals (using multiple BFSs), followed by two BFSs (one for part 1 and one for part 2) of the precomputed data, the total runtime came down to a more appealing ~0.2s. :)
+  :replies: []
+- :author: p_tseng
+  :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbg2tm6/
+  :body: |-
+    58/24. The parsing was the bulk of the difficult work, since BFS is already written and ready to go. I got slowed down on part 1 by type errors (can you believe that I have forgotten how to properly add a single list to a list of lists and had to try no fewer than four times before I got it right?), which is what I get for using a language without static type checking. Did much better on part 2 because it only involved adding another bit to the portals found and adding another dimension to state and by that time I had figured out my type issues. Just had to do a bit of debugging to realise that no, I shouldn't allow traveling to negative depths.
+
+    I just used plain BFS to get on the leaderboard, which was fast enough since it ran in 5 seconds. I have since retrofitted it with the same Dijkstra's that everyone else is doing which gets it down to 0.25 seconds, which I'll call good enough for me.
+
+    My input did NOT have any pairs that are the reverse of each other (AB and BA), so that meant I got away with being very sloppy with my portal matching code. However, since I've now seen that other people do have such pairs in their inputs, I've fixed my code up to actually handle that correctly too.
+
+    ~~Part 2 important note: If you ever go into the same portal more than once, you have repeated a previous position but at a deeper depth and thus you are doomed to wander the halls of Pluto for all eternity. So you could track every single portal you have entered and make sure that you never repeat one, but I didn't feel like keeping track of that in my state so I just did something simpler. If your depth ever exceeds the number of portals, then by the pigeonhole principle you have gone into _some_ portal more than once. So, depth can be limited to be no greater than the number of portals.~~ This has been disproven. I will determine whether there is some alternate way to prove a bound on the depth.
+
+    Ruby: [20_donut_maze.rb](https://github.com/petertseng/adventofcode-rb-2019/blob/master/20_donut_maze.rb)
+
+    Haskell: [20_donut_maze.hs](https://github.com/petertseng/adventofcode-hs-2019/blob/master/bin/20_donut_maze.hs) (Haven't gotten around to adding Dijkstra's to this one yet, so this one's just BFS for now)
+  :replies:
+  - :author: coda_pi
+    :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbg6p0s/
+    :body: |-
+      > Part 2 important note: If you ever go into the same portal more than once, you have repeated a previous position but at a deeper depth and thus you are doomed to wander the halls of Pluto for all eternity.
+
+      Not strictly true. Here's a map where you have to enter the `BC` portal twice:
+
+      ```ruby
+         #############
+         #############
+         #############
+         ### ###
+         ### #..AA
+       ZZ...FG #.#
+         ### BC...BC
+       FG...DE #.#
+         ### #..DE
+         ### ###
+         #############
+         #############
+         #############
+      ```
+
+      I think it may well be the case that you never need to enter level X where X is the number of portals, though.
+    :replies:
+    - :author: p_tseng
+      :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbg9nq1/
+      :body: |-
+        Thanks, confirmed and acknowledged. Correct path through this maze is of length 18, traveling down through BC twice to depth 2 before exiting up through DE and FG. It's what I get for being too clever I guess. I'll strike out the relevant section of my post.
+
+        Note that the map you gave has an interesting property, which is that you can travel from the outer BC portal directly to the inner BC portal. I wonder if it is only the presence of this property that disproves the above principle, and whether the maps given as our inputs lack this property. Or if it has nothing to do with it. I will try to find alternate ways to prove a bound on depth.
+      :replies:
+      - :author: coda_pi
+        :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbgdp1c/
+        :body: |-
+          Actually, I don't think there's a linear bound on the depth (as a function of the number of portals) to get to the fastest solution. Indeed, imagine a map like this:
+
+          ```ruby
+             ############### ###############
+             #.............. --- ..............#
+             #.############# #############.#
+             #.# #..ZZ
+             #.# #.#
+           BD...BE YF...YA
+             ### ###
+           BC...BD YA...YB
+             ### ###
+           BB...BC YB...YC
+             ### --- ###
+           BA...BB YC...YD
+             ### ###
+           BE...BA YD...YE
+             #.# ###
+           AA..# YE...YF
+             ### ###
+             ### ###
+             ############### ###############
+             ############### --- ###############
+             ############### ###############
+          ```
+
+          The hyphens represent having a large number of columns - large enough that any solution crossing the corridor more than once takes more steps than the fastest solution (travelling down to level 24 on the left branch, crossing the long corridor and then travelling up to level 0 on the right branch).
+
+          Of course, it's possible to solve the maze without diving below level 10 - go down to level 4 on the left branch, then cross, then go down 6, then cross back, then go back up to level 0 and cross again to the finish. It would be interesting to determine as a function of X (the number of portals) how deep you need to go to find a solution (I'd conjecture this is O(X)) and how deep you need to go to find the fastest solution (this example shows you need at least O(X^2 ) levels).
+
+          PS This also serves as an example where there's no portal connected directly to itself.
+        :replies:
+        - :author: metalim
+          :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbi2caf/
+          :body: |-
+            That's interesting. So upper bound of levels is around LCM(a,b) where a+b == number of portals.
+
+            Don't think, however, that Eric did any "gotchas" in this task. He's kind. Have you noticed, that even outer portals in the task are on same range of coordinates as inner portals? No portals in corners. All of this was done to avoid any uncomfortable parsing.
+          :replies: []
+    - :author: "[deleted]"
+      :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbg7cdh/
+      :body: |-
+        Nah, whenever you use a portal the second time in the same direction you will end up beeing in the same position as the first time, only some levels deeper. Since start and end are both on level 0 going deeper in levels does not make the solution better.Hence the optimal solution does not have the same portal twice in the same direction in its path.
+
+        I think it would be otherwise if we could use negative levels.
+      :replies:
+      - :author: gedhrel
+        :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbg9trb/
+        :body: 'I think the post you replied to has a concrete counterexample to this statement. You go out twice on the way to the solution: DE -\>(out)-\> DE -\> FG -\> (out) -\> FG -\> ZZ so you must traverse inwards twice through the BC loop first.'
+        :replies:
+        - :author: "[deleted]"
+          :url: https://www.reddit.com/r/adventofcode/comments/ed5ei2/2019_day_20_solutions/fbgbgyl/
+          :body: Ah, ok, now I understand. Thanks.
+          :replies: []

data/data/solutions/reddit/ruby/2019/21.yml

@@ -0,0 +1,89 @@
+---
+- :author: p_tseng
+  :url: https://www.reddit.com/r/adventofcode/comments/edll5a/2019_day_21_solutions/fbllkye/
+  :body: |-
+    The story behind this solution is, as usual, twofold:
+
+    - It's too slow
+    - It's a good chance to test out the capabilities of the Intcode runner, just like [day 13](https://www.reddit.com/r/adventofcode/comments/e9zgse/2019_day_13_solutions/fan6cjr/) and [day 17](https://www.reddit.com/r/adventofcode/comments/ebr7dg/2019_day_17_solutions/fb73yzz/), both of which involved calling a specific function and making sure you've passed the correct arguments to it.
+
+    Even the shortest discovered Springscript programs so far ([four instructions](https://www.reddit.com/r/adventofcode/comments/edocmd/2019_day_21_part_1_all_41_instruction_solutions/) part 1, [six instructions](https://www.reddit.com/r/adventofcode/comments/edll5a/2019_day_21_solutions/fbjujku/) part 2) takes a total 2.2 seconds (parts 1 and 2 combined). Since I'm trying to keep everything around a second per day, this won't do at all.
+
+    It appears that the Springscript runner in the Intcode program just takes too long. A quick examination shows that it gets called over 10000 times on part 2.
+
+    Let's fix that, by replacing the Springscript runner completely. Let's add a [custom opcode](https://github.com/petertseng/adventofcode-rb-2019/commit/edaf07c568f3bcbb74ebc19c26f9e6ccff582d9e) to the Intcode runner. We need to find the address of the Springscript runner function. Finally we need to find the address of the array where the hull is stored. Having done these three things, we replace the Springscript runner function with the custom opcode, then define the custom opcode to perform the "should I jump?" calculation whenever it is reached. That way, the calculation is performed in your programming language of choice, rather than in Springscript. The advantage is your programming language is much faster than Springscript and you're not limited to just two writable registers.
+
+    Ruby: [21_springdroid_adventure.rb](https://github.com/petertseng/adventofcode-rb-2019/blob/master/21_springdroid_adventure.rb)
+
+    Now it runs in about 0.7 seconds, which is within my goal. There could be many more possibilities for the custom opcode, but they require further study of the program before I am able to take advantage of them.
+  :replies: []
+- :author: el_daniero
+  :url: https://www.reddit.com/r/adventofcode/comments/edll5a/2019_day_21_solutions/fbjrxiz/
+  :body: |-
+    Haven't gotten to part 2 yet, just wanted to share how nicely it works with Ruby's heredoc strings to blend intcode and jumpcode:
+
+    ```ruby
+    require_relative 'intcode'
+
+    def run_springcode(intcode, springcode)
+      output = IntcodeComputer.new(
+        intcode,
+        input: springcode.chars.map(&:ord)
+      ).run.output
+
+      puts output.map { |int| int > 127 ? int.to_s : int.chr }.join
+    end
+
+    intcode = read_intcode('../input/input21.txt')
+
+    puts "== PART 1 =="
+    run_springcode(intcode, <<END)
+    NOT A J
+    NOT B T
+    OR T J
+    NOT C T
+    OR T J
+    AND D J
+    WALK
+    END
+    ```
+
+    Haven't looked at other solutions yet, but I solved part 1 manually. The logic is "if there is a hole on either A B or C, but not on D, then jump". Does onviously not work for part 2, so I'll have to work that one out.
+  :replies: []
+- :author: Sharparam
+  :url: https://www.reddit.com/r/adventofcode/comments/edll5a/2019_day_21_solutions/fbiol6c/
+  :body: |-
+    ## [**Ruby** (366/249)](https://github.com/Sharparam/advent-of-code/blob/master/2019/day21/solution.rb)
+
+    Springcode for part 1:
+
+    ```ruby
+    NOT A J
+    NOT B T
+    AND D T
+    OR T J
+    NOT C T
+    OR T J
+    AND D J
+    WALK
+    ```
+
+    Springcode for part 2:
+
+    ```ruby
+    NOT A J
+    NOT B T
+    AND D T
+    OR T J
+    NOT C T
+    OR T J
+    NOT A T
+    OR T J
+    AND H J
+    OR E J
+    AND D J
+    RUN
+    ```
+
+    For part 2 I was playing around and semi-randomly moved the `AND D J` instruction to the end on a whim, and it turned out to be what finalized the solution for me.
+  :replies: []

data/data/solutions/reddit/ruby/2019/22.yml

@@ -0,0 +1,90 @@
+---
+- :author: p_tseng
+  :url: https://www.reddit.com/r/adventofcode/comments/ee0rqi/2019_day_22_solutions/fbnm5sc/
+  :body: |-
+    Part 1 was not too bad, especially since Ruby has `rotate` function on arrays.
+
+    Part 2 was a wild ride. I spent ages exploring irrelevant and useless paths:
+
+    - Let's try it for 10007 instead of 119315717514047. Does the card at position 2020 repeat after a certain time? Well, if it did, it's a long time. Even if it did, how am I supposed to shuffle 119315717514047 cards to find that repeat anyway?
+    - I obviously can't compute a permutation matrix since it's too big.
+    - I wrote code to compute "card at position i is at position j at time t - 1" (undo all shuffle steps). I used modular inverse implementation from 2016 day 15 for this. But I can't apply this inverse function 101741582076661 times. Even a simple loop that does _nothing at all_ `101741582076661.times { }` does not finish in reasonable time on my computer. So how do you even do this?
+
+    I started playing around with the last example given in part 1. I tried seeing what happens if the shuffle is applied twice. The result was... `6 5 4 3 2 1 0 9 8 7
+    ` **Then the light bulb turned on**. That made me see that you can simplify sequences of transformations. I played around to see how to properly simplify the transformations. For example, it's obvious that adjacent cuts can simply be added. Adjacent deal with increment just multiply together (the example has a handy pair of 9 and 3 together to help verify that it's the same as if you'd dealt with increment 7). But to really simplify it into a manageable state, I have to figure out how to transpose any two different transforms so that I could get the same ones next to each other, so had to play around with the examples some more. I used the example and my answer on part 1 to help ensure that my simplified transformations were still the same as the original. When the simplification process is complete, the input contains only one of each type of technique. Once it looked like simplification was working 100%, then I used exponentiation to construct the correct transforms for 101741582076661, simplified that, ran it in reverse (so that "undo shuffle" I wrote wasn't a waste after all!!!), and crossed my fingers hoping that the answer produced was correct. And let out a huge sigh of relief when it was.
+
+    I think I was not mathematically strong enough to see this faster like some people in this thread apparently did, so it looks like I still have some work to do...
+
+    Ruby: [22_slam_shuffle.rb](https://github.com/petertseng/adventofcode-rb-2019/blob/master/22_slam_shuffle.rb)
+
+    Haskell: [22_slam_shuffle.hs](https://github.com/petertseng/adventofcode-hs-2019/blob/master/bin/22_slam_shuffle.hs)
+  :replies:
+  - :author: Fyvaproldje
+    :url: https://www.reddit.com/r/adventofcode/comments/ee0rqi/2019_day_22_solutions/fbqp1xv/
+    :body: |-
+      In my input, there are no 2 adjacent shuffles of the same type. Are there in yours?
+
+      At first, I also tried the repetitions route...
+    :replies: []
+- :author: tckmn
+  :url: https://www.reddit.com/r/adventofcode/comments/ee0rqi/2019_day_22_solutions/fbnilun/
+  :body: |-
+    ruby (plus some mathematica) 91/18
+
+    i had a silly bug in my part 1 that cost way too much time, but part 2 was cool! here's my code and an explanation:
+
+    ```ruby
+    nc = 119315717514047
+    a,b = 1,0
+    read.lines.reverse.each do |line|
+        case line.chomp
+        when /new/ then a,b = -a, -b + nc-1
+        when /cut (.*)/ then b += $1.to_i
+        when /increment (.*)/ then a *= m=invmod $1.to_i, nc; b *= m
+        end
+    end
+    p a%nc,b%nc
+    ```
+
+    i then stuck the constants into mathematica (because i had the foresight to prepare a modular inverse in ruby, but somehow not a powermod) and solved the problem with this expression:
+
+    ```ruby
+    Mod[2020 PowerMod[a, n, nc] + b (1 - PowerMod[a, n, nc]) ModularInverse[1 - a, nc], nc]
+    ```
+
+    the basic idea is that all the shuffles can be described as operations modulo the card count.
+
+    - the reversal maps position _p_ to _-p + nc-1_ (where _nc_ is the number of cards)
+    - the cut by _n_ maps position _p_ to _p - n_ (which generalizes to negative _n_)
+    - the deal by _n_ maps position _p_ to _pn_
+
+    therefore, we can fully describe the entire shuffle transformation as _ap+b_ for some constants _a_ and _b_. specifically, they start out as _1_ and _0_ respectively, and each line in the shuffle procedure modifies them as follows:
+
+    - reversal: _(a, b)_ → _(-a, -b + nc-1)_
+    - cut: _(a, b)_ → _(a, b-n)_
+    - deal: _(a, b)_ → _(an, bn)_
+
+    we actually want to invert these, though, because we're asked for the card that ends up at 2020, not where 2020 ends up. the inverses are simple, because reversal is its own inverse, cut by _n_ just becomes cut by _-n_, and for the deal we take the modular inverse (the number of cards is prime). we also need to make sure to apply the steps in reverse order.
+
+    after that (which is what the ruby code does), we have to apply the function _x → ax+b_ a large number of times. taking a look at the expanded version of the first few applications gives a clue:
+
+    x
+
+    ax + b
+
+    a^(2)x + ab + b
+
+    a^(3)x + a^(2)b + ab + b
+
+    a^(4)x + a^(3)b + a^(1)b + ab + b
+
+    in general, the _n_th term looks like
+
+    a^n x + a^n-1 b + a^n-2 b + ... + a^2 b + a b + b
+
+    which can be factored into
+
+    a^n x + b(1-a^(n))/(1-a)
+
+    the mathematica does this all mod number of cards, which gives the solution.
+  :replies: []

data/data/solutions/reddit/ruby/2019/23.yml

@@ -0,0 +1,10 @@
+---
+- :author: rsthau
+  :url: https://www.reddit.com/r/adventofcode/comments/eefva8/2019_day_23_solutions/fbthisd/
+  :body: |-
+    Ruby: [both parts](https://topaz.github.io/paste/#XQAAAQBRBAAAAAAAAAA5GUqKNoFH6SMqVwZFsYYqxh4FnZ09RieSSH8z3H6sL03AUlcQkmRnBspAYbyTvczaqGyugOtst3YC3kVpS4F56jNFbmJSnrpqLE9hxeC6BKQA0LPyX/ox6A+hav4qWQ4muJAdqpu70P6TfjJ/nXvlsc5u/twj9HLrvG+pD699I+/OVuFyQ7bGUGGNKQA3z/gIOWuJvpjUpULx0QcIzsJVykfXIsglcsgnVynBcLTUtsYIU1hO2eP+uBACXoAStoj2Fe4kOj0gDjUIFPbJ3paq9Dt9J1YH8RBS3rdYq4txRE+eR1U426ssaSNX/VyuiMn6FtGCEpOyB4kJq53HEQG+ZbmjLZwU+8sl8d/CKjyb1vrm/qjVsqIU/b0+wXbN2vRFL6mOfepRjH5tBKZffcFNJxR1NSj7xKiov3F8B6Ko2LBYeKg5Q/iXBFAtdBYh7byPS7PvM/J5EJZ52cEqcgKxYwN6uzz7kXKYr9/+I/zqLsCs7uUmgo10Ny/t/u/4TZmwtsxrzwIM2F+W/hfJAbHPZtvTfPedP8Gc0mKKOPH7E2xfCySnO3j8QEQ6COz0wIRoqp1Sh/ycHB6Gcn+xJQWn50E+aHqa010rHGPVNZYdQORhwxVMebSevAIRkIzyIY3cGxwXgdZ2Pa7ZYbabnVA9UzEuYZ+v/qmfXA==)
+
+    My Intcode machine interface has been set up for this sort of thing since day 7; it seems to have worked out pretty nicely here. If my intcode machines I had explicit input queues instead of the provide\_input code which lets external code manage provision of input, the non-blocking inputs would have been somewhat more awkward to handle.
+
+    (As you can see, the machines do have output queues; the way this works is that on startup or after receiving any input, the machine proceeds as far as it can, putting up any output generated into its output queue; this stops when it either halts or blocks waiting for external code to provide another input.)
+  :replies: []

data/data/solutions/reddit/ruby/2019/24.yml

@@ -0,0 +1 @@
+--- []

data/data/solutions/reddit/ruby/2019/25.yml

@@ -0,0 +1,40 @@
+---
+- :author: p_tseng
+  :url: https://www.reddit.com/r/adventofcode/comments/efca4m/2019_day_25_solutions/fc4qi6w/
+  :body: |-
+    Solved it day-of with mostly manual playing plus machine assistance (replay a list of moves so that I don't lose all my progress, brute-force the pressure pad). I've since gone back and added some nice bells and whistles to the game player, as follows:
+
+    - With the -s flag, prints all strings present in the program. Please excuse some garbage that gets printed out, since there are some segments that look like strings but end up not being strings and I don't bother to filter them out.
+    - With the -i flag, prints all items, their weights, their locations, and the address of the function that will be executed if that item is picked up (if any).
+    - With the -r flag, prints all rooms, their flavour text, the item(s) that room contains (if any) their neighbouring rooms. Colour-coded.
+    - By default, with no flags, calculates the answer the program will eventually print, with the following procedure:
+      - Look for the string containing "airlock" in the program
+      - Looks at what address is printed right before the string containing "airlock" is printed
+      - Looks for a function that writes a constant value to that address (that function writes the constant 0 to clear it in preparation for doing real work with it)
+      - Inside that function, looks for the multiplication of two numbers to form a reference value. Remembers that value and its address.
+      - Looks for a function that performs any comparison operation against the reference value by address.
+      - Looks for the base of the array used within that comparison function.
+      - Computes the answer using that array and the reference value.
+      - Yes, I know that the relevant addresses are actually the same for all inputs, but I dislike having too many magic numbers in my file without any explanation of where those numbers came from. Thus, having the code perform the above-listed operations serves as documentation for me for what the program is doing.
+    - With the -m flag, lets you play the game manually. The game is enhanced with the following additional commands:
+      - "sa <savename>" (short for "save") saves your current state.</savename>
+      - "l <savename>" (short for "load") loads the named state. Note that there is a save named "auto" created every time you successfully move from one room to another.</savename>
+      - "i" shows all items and their current location (whether that be in your inventory, or in some room), much like the -i flag.
+      - "r" shows the rooms, much like the -r flag, with your current location in red, and shows the sequence of movements you must take to reach any particular room
+      - "ft <room>" (short for fast travel) travels to the named room by providing the correct movement commands that would do so. You can be pretty imprecise with the room specification; first it tries substring matching, then it tries <em>subsequence</em> matching.</room>
+      - "ta" or "takea" or "take a" (short for take all) picks up all items that do not execute a function when they are picked up, by providing the correct movement commands that move to the room they are in plus the "take" action. No optimisation of routing is performed; the items are simply taken in the order they appear in the program.
+      - "b" brute-forces the pressure pad, showing its progress as it goes.
+
+    Since everyone likes screenshots, [nice screenshot showing the colour-coded outputs](https://i.redd.it/whzl7y6g34741.png). (I censored out my answer)
+
+    Ruby: [25\_cryostasis.rb](https://github.com/petertseng/adventofcode-rb-2019/blob/master/25_cryostasis.rb)
+  :replies: []
+- :author: rsthau
+  :url: https://www.reddit.com/r/adventofcode/comments/efca4m/2019_day_25_solutions/fbzpb4q/
+  :body: |-
+    Ruby: [Code](https://topaz.github.io/paste/#XQAAAQAoBwAAAAAAAAA5GUqKNoFH6SMqVwZFsYYqxh4ExTaLbtf8Alp69UGP9KkSBesmiuVUTdimvKqEHp35RFKztzBU/3FuJv5lldOij8/JmL+Q2WHcQ2y5zCd3FMTB2QOR4oSaHdfg68+rfvTp3WjqEKnUngRyjKlgsL8NxEnXKOBDpzriYeY3qRCQqNNxt1jdGMjJWGzttNCPEZAWwT9c20OyEVP/dmRGJPRlbp9komCqWOQNtHmpFu6v10Qb2awX767abSGKOT3Qui5YZ8EaPN7IvMQCdZPtlN2qfHKzb6TmFeqm6p1WlNCr/2E5o8eR9SEmBALNYIbosLTThyg1JsTaJzTM+dt9gHkG1E3lX0T+vwtVNuXqipmD7jBg4/WZSNDymSifBwjuWg7mflb09TjZdE4lOj+Lu5qS3+IizAdQJ0+YxES3tzBn6qbKOvmTpKh9/NZwW6Bi2yFAoVTOW/VnNBacDOFs8vDG9FE2S6+yKnwWQjnn6DhHDqP2spqMwnJadQgKXz5WQz5YLC4CBnjD4OmQ3HraPN2ioGzjG1dAHCnh22Nx86gNXGD0RHe7Y47TwPgrfXRz64gilLnYH6uTGIMa0Y2JiPLauN6xgaulVWD1sxonlBg8nBU4p9ZXmrI5Jeue3sY6LR7SFEQtJDuB/FlfJpEfNIo6TmHe0RxUzHRQBwOAS5Ao6fQ/1yQX9BRIuIxGnxtLC6Kiz8Yy+P4JtZuqn/0zV1tMZnTN/I9jJdTSlMiY/nv7mUtmLTTelcukouy9b6WvStQqdozCfNoL8df3veLO4sKGzPKCFJaJw0eLspdeCN6FbXo/om+aif3mndfsaJm43ulZPGeGJGg7ZvPZDL/7sroAqYUjlK78jAtQBlsRghtWYqdV1sgaH4HqSr9EwgMnWvjDNiG5X4+P5udHFeeZJu/1jO34jzBYl7XUPFjoFAgqCl2hUA3L6+J7jfCy9jnj6ffaUuPq6ClGqIAMHVU17ru3XhzUkKU+j99wJNH+tfjYZKGp3Y65aB768VqS)
+
+    I manually mapped the ship collecting every item which wasn't fatal to touch ("take infinite loop"... #$@%#%@#%), but once I got them all to the security checkpoint, sorting through the pile to find the right items wasn't my idea of fun, so I automated that. (Note that the code which does this is particular to the set of items in my input; from what I see here, your mileage _will_ vary, but replacing my list with anybody else's should be straightforward.)
+
+    To facilitate debugging this, and also for all the usual adventure-game reasons, I also wound up implementing "save" and "restore" commands. When my command-reader sees these commands, it doesn't send them to the Intcode machine, but rather invokes code which either writes its state out to a file, or restores it. A third meta-command ("dance") initiates the pile-sorting process.
+  :replies: []