Discussion thread for day 1 of the Advent of Code - https://adventofcode.com/2025/day/1
. . . FIRST?!
Definitely took longer than it should have... spent way too much time last night debugging the smallest of issues...
20% build, 80% debug... off to a strong start 😂
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.
Yay! Starting off with 2 stars!
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
Returning to my favorite time of year.
Work priorities make it so I can't chase times this year, which is probably better for my health anyway.
Part 1 was straightforward other than the usual case in the data but not in the sample.
Part , thought about elegant math solutions involving mod 100 and such.
Then realized that if you break L68 into 68*L1 then you can solve Part 2 the same way as Part 1.
Generate rows is, as ever, the Alteryx equivalent of outsourcing if outsourcing actually worked.
Twas' the first day of AoC....
Part two took a bit more thinking than I expected, but it was a fun start to the AoC!
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:
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.
First time ever participating in AoC and it did not disappoint. I was able to solve for the first task pretty quickly, however, when I went to reference that work for task two, I found a flaw in my logic that, interestingly enough, it still produced the right answer.
Problem was, it didn’t help me with task two. So, I re-tooled that part and moved on to task two.
…and wrong-answer-jail for 5min…
Kept at it and got the answer on my next attempt!
Solution and explanation below:
Workflow:
Narrative:
Okay so Task 1: Since we know the dial has 99 values + zero, it’s 100 values, which makes for nice division; however the MOD() function also works to help repeat the values on a base 100 scale.
Computing the Dial Location is where I got lucky on my first task and still got the right answer despite flawed logic. I was computing the location of the zero’s just fine, but I wasn’t actually showing the correct dial location. When 5 went left by 15, I was showing a -10 (or 10 with absolute value) instead of the correct value of 90…
A quick change to the formula produced: IF Mod([Delta], 100) >= 0 THEN Mod([Delta], 100) ELSE 100 - Abs(Mod([Delta], 100)) ENDIF
Filter down to zero’s and sum ‘em up.
Task 2: This is where I noticed the issue with task 1, but now that I have a working Dial Location, I could break this into three section:
The reason for the three, is my method subtracts the movement from 100, but when it’s starting at zero, it needs to see that as “100” and not “0”.
Apply the FLOOR() function and now I can see how many times it crosses 1 when divided by 100. Why I chose MOD() for T1 and dividing by 100 for T2 is anyone’s guess.
The Multi-Row-Formula Tool was my friend for both Tasks, but here is my logic for Task 2 before counting occurrences for the solution:
IF [Direction] = "S" THEN 0
ELSEIF [Direction] = "R" THEN Floor(([Row-1:Dial Location] + [Clicks]) / 100)
ELSEIF [Direction] = "L" AND [Row-1:Dial Location] = 0 THEN Floor((([Row-1:Dial Location]) + [Clicks]) / 100)
ELSEIF [Direction] = "L" THEN Floor(((100 - [Row-1:Dial Location]) + [Clicks]) / 100)
ELSE NULL()
ENDIF
Phew okay, now that we’re through day 1, I anticipate the difficulty to start ramping up. Cheers and on to day 2… hopefully.
-Jay
It seemed too easy, maybe because I added 50 as the first line of the input file? I'm uploading before I look at other solutions so I'm not tempted to make mine more efficient
Did anyone also code this? I wonder how much more efficient Alteryx is. I think this took about 15 minutes total.
I stashed pretty much everything into formula tools except for the multi-row formula, which does the majority of the heavy lifting with respect to seeing where each rotation lands. Modulus was a huge lifesaver for me, in a number of ways!
This was my first ever Advent of Code challenge! I have been looking forward to this challenge since I heard about it so I am happy to be 1/1 to start the month. Happy December!
First time joining advent of code. 'Twas a fun challenge!
Multi-Row and Generate Rows Tools to the rescue!
Day one done, a little difficult for day one. I may get stumped quickly.
Day 1!
It's that time of year again!I'm both happy and sad that there are fewer problems.
Even though it was the first day, I had quite a bit of trouble.
The workflow is simple, but part two took quite a bit of trial and error.
Even when exceeding 100, the R-side calculation remained straightforward. However, when L exceeded 100, or when it started at 0 or ended at 0, incorrect calculations frequently occurred.
Therefore, for cases where L was greater than 0, I adjusted the start position to (100 - start position) and calculated it the same way as R. Also, even if L was involved, when the start was 0, I used the same calculation as R.
I believe there are better approaches, so I look forward to seeing everyone's solutions.
saw a lot of same approach. good challenge for mod function
- add initial line instead of manipulate multi-row. - use generate row to +-1 instead of complex formula.
- use mod to limited to 0-99
Did I get lost in the weeds for a bit doing convoluted if/then statements? Yes. Will I learn my lesson for future days? Probably not!
The challenges on Day 1 were quite interesting.
Day 1, great fun!
Nice and easy to start with, and I had one of those builds where I accidentally answered part two from building part one.
I began by using regex to parse out the bits of each turn, namely the Direction letter, the last two digits (I'll come back to this) and the leftover. To do this I used the following:
I parsed the last two digits as we only need these to determine the move. 762 is the same as 62 for part one, so I simply chopped it into three:
I then used a multi-row to determine position:
This gave me the answer for Part One, and given I had split the original data into three columns, the "leftover" bit was essentially the extra clicks, given these were numbers of hundreds, which would always be an extra click per hundred, and so I simply needed another multi-row formaula to determine the number of clicks from the actual moves, then add the hundreds:
Then simply sum this column.And Robert's your father's brother.
A nice start to AoC. Probably the only day I'll get a chance to do this, but here's hoping.
M.
Some refactoring needed for step 2 but we got there.
I love my multi-rows.Filter for Part 1, summarise + filter for part 2.
Definitely didn't do this the most efficient way, but it works!
As the approach for Part 1 did not work, I started from the scratch for Part 2, and it worked.
Firstly shout out to @clmc9601 for he fantastic starter kit Gave that a little tweak to use my own template and @cgoodman3's testing macro to make this so much smoother
and
Day1.
Just realised I hadn't posted yesterdays solution! Good challenge to get the brain working on a Monday morning!
