Advent of Code 2020 - BaseA Style (Day 13)

Jean-Balteryx

Discussion thread for day 13 of the Advent of Code : https://adventofcode.com/2020/day/13

Advent of Code

Accepted answers

All comments

cgoodman

Here's my Part A.

Spoiler

Added in the tools at the end to get to single cell answer.

Part B I don't think is an iterative macro, I think it's a case of getting a calculator out.

jdunkerley79

Here's my solve - BaseA for 95% but needed some true integer maths for last part

Spoiler

All maths for part 2 - googling "simultaneous equations modular arithmetic" reminded me of the maths I had long since forgotten

But had to use Python tool to correct for inaccuracy in double arithmetic.

Will do a version with some Abacus functions

dsmdavid

When I need to use pen and paper I know I'm in trouble. What a brain melt! I did it baseA with an iterative, works with my input. Once the headache leaves, I'll try to read and see other people's solutions 😅

Spoiler

and the macro

A summary of my thought process:

Spoiler

I began with pen and paper, then some excel(highlighted = 54):

I started with
number 3, offset 0
number 5, offset 1
number 7, offset 2
number 11,offest 3

3&5 --> the first number that qualifies is 9 (mod(9,3) = 0 && mod(9+1,5)=0).
Then I need to find a number that qualifies for (3,5) and 7. I start with the first number that qualifies for the previous condition, go in increments of (3*5) --will all keep qualifying for mod(z,3) = 0, mod(z+1,5) = 0 -- until I find one that qualifies mod(z+2,7) = 0 (the first number that qualifies is 54)

For the next, I'll start at 54 and increase in increments of 105 (3*5*7) until I find one that qualifies mod(z+3,11) =0. (789).
And so on.

day_13_01.yxzp

NedHarding

Part 2 was hard! I don't know anything about the Chinese Remainder Theorem... And I wasn't finding any simpler solutions. So I cheated and read @dsmdavid 's solution! Brilliant! Somewhat embarrassed I didn't come up with that on my own. Anyway, I did it first in Excel and then in Alteryx as an iterative macro. So simple.

https://github.com/NedHarding/Advent2020/blob/main/Day13.yxmd

While I was headed the other direction I wrote a quick infinite precision multiply for Alteryx. Did anyone but me know the summarize tool already does infinite precision for fixed decimal sums!

https://github.com/NedHarding/Advent2020/blob/main/BigMult.yxmd

patrick_digan

Happy with my solution, I noodled on it all day before it finally hit me

Spoiler

Part 1 was pretty simple, but for part 2 my logic went like this: for the sample with 17, x, 13, 19 Start with bus 17 and bus 13. Since bus 13 needs to be 2 minutes after bus 17, we need to check bus 13's next arrives after bus 17 plus the necessary space. So when bus 17 returns at 17 and then we add the 2 minutes, bus 13 would next return at 26. This is 7 high (26-(17+2)), so we need to try at the next stop. At 34 minutes, bus 13 would be at 39 minutes. Again, it's 3 high (39-(34+2)). Keep going until you get to 102 minutes. Bus 13 would next return at 104 (13*8). This is 2 higher. perfect! Now in order to keep these 2 in sync, we can keep adding 221 minutes (13*17) and bus 13 will always be 2 minutes after bus 17. Now we add in bus 19, which needs to be 3 minutes after 17. Our first check is when bus 17 returns at 102 plus the 3 minutes. Bus 19's next return is 19*6=114. This is more than the needed 105. So we add 221 to 102=323. Bus 13 and bus 17 are still in sync. Bus 19 would next return at 342 compared to the needed 326. Still too high. This goes on until 3417 where bus 17, 13 and 19 are all in order. If we needed to add more buses, we would then add 221*19=4,199 minutes to keep all 3 in order. Since there really isn't that much math going on, my solution gets there in a couple seconds. The engine is really 1 generate rows tool inside my iterative macro. And I'm using too many multi-rows, but I didn't feel like cleaning it up.

EDIT: I think my logic is similar/the same as @dsmdavid

Day13.yxzp

T_Willins

Number patterns. Thankfully they used all prime numbers. For part b it led to an iterative macro inside of an iterative macro, an iterative-ception, a dweam within a dweam...

Spoiler

For me finding the pattern was key. It's similar to the mod approach, but attacks it as an iterative approach. Since the numbers are all prime, each additional bus (prime) adds to the multiplier for the next set inside the iterative macro in the iterative macro, so 13 looks by 7s, 59 looks by 91s (7*13), 31 looks by 5369s (7*13*59), etc. If the numbers were not prime, then least common denominator comes into play, which could be determined by subtracting the first valid number from the second valid number to apply to the next iteration. In the case of the first sequence it would be 168-77 = 91 for the multiplier for bus 59. Since each iteration looks at numbers going up by the multiplier, the macros get to the answer quickly. This ran in 3.4 seconds.

Workflow

Iterative Macro

Iterative Macro 2

13a&b.yxzp

Quick Links

This months top contributors

atcodedog05 19458

Qiu 15866

binu_acs 15708

MarqueeCrew 13708

apathetichell 13703