General Discussions
Discuss any topics that are not product-specific here.
Day 1 done! A huge shoutout to @OllieClarke - flashed me a screenshot of his workflow and made me realise I could just use a Multi-Row Formula for what I was trying to brute force in a 550k-iteration macro.
There's definitely a better way of doing this, but I was surreptitiously solving while on calls, so didn't have the brain space to think about clock maths
Part two took a bit more thinking than I expected, but it was a fun start to the AoC!
My approach for both parts actually revolved around running totals. Some of the other solutions people have posted take a much smarter route to help with part two, but here's my thinking:
Part 1:
1) I began by separating out the direction and the numeric value using some regex:
2) To make life easier, I decided to convert all the "Left" moves into negative numbers, and leave the right ones as positives:
3) Next i needed to account for the fact we started at 50. I did this by simply unioning a record with a value of 50, onto the top of my other data. (Yes i originally forgot about this, so was frustrated with myself when I realised this was the issue, but I made it in the end).
4) As my left and right values, were represented as negatives and positives, I didn't need to consider their directions separately. Instead, I could just create a running total!
5) This does mean I now have some records with a position outside of the range 0 - 99 but that didn't actually matter too much. As there were 100 numbers on the dial, I knew that any multiple of 100, is actually pointed at 0. With this in mind, all I had to do was filter to the records where the running total was a multiple of 100, and the count how many of these records there were:
Part 2:
For part two, I simply continued on from the running total step, created in part one.
1) As I had used a running total, I decided I needed to have an ID which indicated which "multiple of 100" my data was say within. i.e
- 0-99 would be 0
- 100-199 would be 1
- (-99) - 0 would be -1 etc...
I called this "ID", "Hundred component".
2) Next the premise was relatively simple to implement by using a multirow, but there were a few edge cases that needed to be accounted for. All I wanted to do, was say, if the "Hundred Component" changed, then it means I have passed 0. This holds because if you consider the following
- Start on number 47, (with a hundred component of 0).
- Rotate to 134 (with a hundred component of 1).
- Calculate the difference in the "hundred components", 1-0 = 1.
- Therefore I went past the starting point (at 0), 1 time.
However, the edge cases included the following:
- If you start at 137 (hundred component of 1)
- Move to 100 (hundred component of 1)
- Move back to 152 (hundred component of 1)
These all have the same "Hundred component" meaning my previous logic would not hold.
Fortunately, it was possible to fix this by simply adding a couple of "If statements" into my multi-row, to explain, that if you are currently on (or were previously on) a multiple of 100, then you need to either add 1, (or not add one) to the number of full rotations, given by your last move. Please see multirow below for further detail:
3) Finally, it was just a simple case of summing up the column created by the multirow.
