I...again don't fully understand what I've done here. After reading the problem and printing out the binary representation of x + y and z, I looked at the bits that weren't correct and started trying to reason about why that might be. Manually swapping around outputs started to yield some results, so I hacked around until I got something that worked and submitted that answer. Once I had it by hand, I went searching for help on Reddit for how to solve this programmatically, and found a lot of chatter about half-adders and junk, so this is implementing some posts I saw there to search for the incorrect sequences and rewire them.
I solved this initially in a way that took around 15 seconds to run (check every possible combination of computers to see which ones were all connected), then did some research and found the "Bron-Kerbosch algorithm" for solving this problem, and wouldn't ya know, a named algorithm solves the problem way faster than brute force. Funny that.
Cut out tuples to save a large amount of time
This is also more correct/accurate in that it stores the total for all sequences across all buyers rather than requiring the best sequence to be in the first buyer's set.
Finally, it turns out that the float divide/truncate was unnecessary and also costing some time.
In the debugger, part 2 now finishes in around 675ms. Debug config outside the debugger is done in 360ms, and Release in 200ms. Good enough for now, I think.
This one was a real doozy. I was all kinds of twisted up trying to find a valid solution here and built + threw away at least 3 implementations that each _almost_ worked.
Part 2 was a doozy. I sought some help online for understanding what the program was doing and how to feed it an input to get the output we were after.
Everything about this is awful, but it was my first idea for implementation and it got the right answer...eventually...so whatever. I'll probably fix it later. Maybe.
I'm sure there's a more elegant way to handle part 2 than my hackneyed "now check against two points instead of one", but this works and comes in a hair under 500ms on my machine, so...I'm not too broken up about it.
I had no idea what to look for, so I wrote a rudimentary (slow) detector and it worked out.
See comment in part 2 for explanations of why this only works with my input...
This one is sloppier than I'd like, but these visual problems always throw me for a loop anyway. I was lucky I was able to use the ugly "num corners" trick quickly here.
Part 1 is pretty ugly, but fast. Part 2 is slower than I'd like (~200ms in Release) so I may revisit, but it's fast enough for now. The slowest part seems to be FindIndex on the gap list.
Took me a little while to understand the problem, but once I did, ivec2 came in clutch once again.
Would have had part 2 sooner if not for the "also all antennas are now antinodes" thing which I just missed. You win again, reading comprehension.
Okay, this optimization was easier than I thought it'd be.
I started by not building a new list every time I wanted to operate on the next value since that seemed like low-hanging fruit. That helped, but not as much as I expected (as is always the case with optimization, I feel).
Next I ran this under a profiler and it showed that string concatenation was the biggest offender, so I found a way to do that without involving strings (it's a bit convoluted, but optimizations tend to do that...) and that cleaned up most of the problem.
After that, getting the next element from the list was a (very minor) next-highest offender, so I cached that locally.
Finally, on a whim I decided that the tuple wasn't helping me anymore, so I removed it and was surprised to see another 100ms or so disappear. I guess constructing those is worse than I thought...gotta file that away for later. I'm a little surprised that it didn't show up in the profiler (or I didn't know how to read it, perhaps).
Part 2 gave me more trouble than it should have, mostly because I was initially turning and stepping at the same time which ended up being a big mistake.
This runs in a few seconds in Debug, but only a half a second in Release. I feel like it can be much faster, but I don't have any ideas on doing that just yet.
It took me a minute to figure out a good solution for part 2, but I'm pretty happy with the custom-sort-function implementation.
I also really like the LINQ one-liners for getting the actual totals. I feel like future-me is going to be mad and confused, but right now it feels fun!
This solution feels pretty bad. I think I shouldn't have used my ivec2 utilities and just checked the next spots for part 2. It would probably have been simpler given all the constraints. I'm also certain there's a smarter way to solve this than what I did, but...it works, so...?
Since we no longer include input files with the solution, per AoC guidelines, this will enable other users to use this application (after specifying their session token) without manually grabbing all the appropriate download files.
