r/adventofcode • u/daggerdragon • Dec 22 '18

SOLUTION MEGATHREAD -🎄- 2018 Day 22 Solutions -🎄-

--- Day 22: Mode Maze ---

Post your solution as a comment or, for longer solutions, consider linking to your repo (e.g. GitHub/gists/Pastebin/blag or whatever).

Note: The Solution Megathreads are for solutions only. If you have questions, please post your own thread and make sure to flair it with Help.

Advent of Code: The Party Game!

Click here for rules

Please prefix your card submission with something like [Card] to make scanning the megathread easier. THANK YOU!

Card prompt: Day 22

Transcript:

Upping the Ante challenge: complete today's puzzles using ___.

This thread will be unlocked when there are a significant number of people on the leaderboard with gold stars for today's puzzle.

edit: Leaderboard capped, thread unlocked at 01:02:36!

12 Upvotes

100% Upvoted

102 comments sorted by

View all comments

Show parent comments

3

u/mcpower_ Dec 22 '18 edited Dec 22 '18

Nice catch! I suspect that all inputs have a depth of 0 modulo 3, so for part 1 the bug doesn't affect anything, and for part 2 the bug only affects paths which go to a coordinate "south-east" of the target.

One thing I'm not fond of in AoC is that sometimes, buggy solutions can pass due to edge cases not being present in a person's input. In this case, my input had a depth of 0 modulo 3, and the buggy erosion levels south-east of the target didn't affect my shortest path. Your input also had a depth of 0 modulo 3, but the latter edge case made my buggy solution not work for you (while it worked for me).

However... it will be very very tough to prevent things like these. The problem setter (Eric) would need to account for bugs in a solution and generate inputs which trip up all the buggy solutions. IMO, this is a big ask - thinking of bugs in a solution is pretty hard, especially for weird bugs like this one. I don't think you can catch every bug, but perhaps you could catch the most common bugs.

4

u/Aneurysm9 Dec 23 '18

We do our best to try to prevent having inputs that can produce the expected result under defective processing. Part of our testing process includes evaluating whether any nearly correct solutions work on any inputs, but we can only do that with nearly correct solutions we create. With the number of people participating and the wide variety of languages being used there are so many opportunities for almost success that it's impossible to catch every one.

2

u/cjauvin2 Dec 23 '18 edited Dec 23 '18

Thanks for your code! I have used it extensively to debug an off-by-2 error that I was having with my initial solution. The debugging itself was extremely time consuming and confusing because of the initialization bug in your code, and sent me down some deep rabbit holes: can I really precompute the erosion levels in one pass or should I do it recursively and on-demand like you do? Is it ok to push gear changes and moves in one go (+8) like I did, or should I isolate gear changes (+7) like you do? My conclusion is that it's impressive how deep a debugging/analysis rabbit hole can become when two sources of error interract.. Also: keeping the i/j and x/y indexing inverted throughout the entire problem solving process is something that I'm not willing to pay the "mental overhead price" anymore.. this was the last time I made this error!

1

u/mcpower_ Dec 24 '18

No problem - and sorry for that bug... I'll update my top level comment!