Advent of Code 2024 Day 6 (BaseA Style)

AlteryxCommunityTeam

Discussion thread for day 6 of the Advent of Code - https://adventofcode.com/2024/day/6

Advent of Code

Accepted answers

All comments

JoshuaB

This is precisely when you realize Day 6 is hard 😂 No Solutions yet posted!

ScottLewis

I'm reasonably confident in my solution. It's just that I estimate the runtime at ~600 hours.

That was the point at which I chose sleep.

CoG

My solution, Part 1 is fairly quick, but Part 2 took 1hr and 10min to run:

My First Solution:

Spoiler

Main Workflow:

Spoiler

Move Guard (Iterative Macro):

Spoiler

Part 2: Place Obstacles (Batch Macro w/ Move Guard macro nested inside):

Spoiler

Tried to optimize in a few different ways. One of the biggest optimizations that can be made is recognizing that obstacles only need to be place on the original path of the guard, otherwise, it will never be encountered and a loop will never be generated.

Place Obstacles.png

Amazing Solution (Thanks to @gawa for the idea to not nest macros): With the power of smart optimizations and memoization of the guard's corner stops this workflow solves Day 6 in 2 minutes and 30 seconds!!!:

Spoiler

Part 1 Macro (Move Guard V2):

Spoiler

Part 2 Iterative Macro (Move Guard V3 - handles adding 1 obstacle):

Spoiler

Pretty Picture of Part 1 Guard's Trajectory:

Guard Path.png

Main.yxzp

Main V2.yxzp

Sebastian_Chaieb2

This one is really hard 😂

First Part was running 17min and Second I have to fine tune as it will run forever :P

Spoiler

And iterative macro

Day6_Star1.yxzp

mmontgomery

Sheesh. More in spoiler

Spoiler

P1 wasn't too bad to map out the logic and brute force your way to unique steps
P2 took a while to figure out the setup that got me exceptionally close to the answer (off by single digits) and just guessed til I got it.

My approach was this, I needed four datasets:
1. Main map;
2. Existing boundaries (outside map listed as E for exit that I generated and # for current blockers);
3. Current Starting point;
4. Individual steps I got from P1 used a new boundary to generate a brute force batch macro

The goal was to determine if a given step would result in E for exiting the map or # for hitting a loop. My logic for hitting a loop was a point and direction combo that was previously seen in the path.

To make the batch macro more optimal (45 minutes vs endless) I just jumped ahead from any given point to the nearest boundary it would hit: # or exit E. If it hit a boundary in play, generate the new point similar to P1 and loop, if it hit an exit then the macro would end, as well as running into a previously seen path and direction.

Day 6_MM.yxzp

DataNath

Very satisfying to get this one cracked. Originally didn't have a clue how to tackle it but tested out a few approaches and got there in the end. P1 runtime was 1.7 seconds, P2 was 1 hour 42 mins. A huge thanks to @CoG for the golden tip on optimising iterations!

Spoiler

A couple of useful pointers:
1) Keep a stored list of visited points and the direction - a loop is when you return to a matching point & direction
2) There's no need to run through every point - with the right logic you can 'jump' to the next obstacle-1, and generate a list of 'visited' tiles
3) You only need to insert extra obstacles at tiles you visited on Part 1 as you can't get to the rest of the grid

Main workflow:

Day 6 - Workflow.png

Part 1 iterator:

Day 6 - P1 Iterator.png

Part 2 batch:

Day 6 - P2 Batch.png

Part 2 iterator:

Day 6 - P2 Iterator.png

Gawa

Brute force way. For part2, it'll take 8 hours in my computer😂😂😂

(Edit_ve2)

Instead of nested macro(Iterative Macro inside Batch Macro), I made attempt by single Iteration Macro, that run within 15min.

I maintain the same algorithm(brute force) as previous attempt but running time got much faster.

Nested Macro is 'easy for human to understand' but 'not easy for Alteryx to process'...maybe.

2024D6_gawa.yxzp

2024D6_ver2_gawa.yxzp

AkimasaKajitani

Solved!

Day 6 is toooooo hard. Normally this difficulty puzzle is served after day15.

Spoiler

Day 6 is toooooo hard. Normally this difficulty puzzle is served after day 15. But I finally solved day 6 at 10 minutes before the start of day 7.

Part 1 macro (moving the path step by step):

This is not fast, but it is needed for part 2 input.

Part2 Batch macro(Place obstacles one by one from the path of Part1 and start the infinite loop detection macro):

Part2 finding the infinit loop macro :

Part 1's step by step macro is toooooo slow, so I had to re-create the macro. This macro will jump as far as possible in a straight line. But it is still slow. It took 2.5 hours to solve.

To solve faster, I think that the gawa's parallel approach is needed.

Day06.yxzp

Hub119

Was too tired to post this in the wee hours of the morning when this FINALLY finished running... if I don't sleep, why should my computer be allowed to? (Note: this took even longer than it needed to as I FORGOT to disabled my computer's ability to go to sleep after set intervals until part way through... Part 1 runs in a couple seconds at least... doing so thousands of times however for part 2...)

Spoiler

Workflow

Iterative Movement Macro

Batch Macro

AoC 2024 Day 6.yxzp

DaisukeTsuchiya

I spent a long time for P2 but finally my WF can run in 23 sec for P1 and P2.
I got the idea from @gawa to avoid nested macro.

Spoiler

<P1 Macro>
スクリーンショット 2024-12-08 072142.png

<P2 Macro>

スクリーンショット 2024-12-08 072216.png

I use spartial tool for debugging.
スクリーンショット 2024-12-08 073715.png

DT2024_Day6_Rev5.yxzp

ntakeda

My solution...

I went on a trip, and by the time I came back, the answer was output (it took about 3 hours).

Spoiler

AoC2024-part6_2.yxzp

AoC2024-part6.yxzp

AncientPandaman

part 1: 2 mins > 9 seconds

part 2: 12 hrs > 1hrs > 10 mins

python take 15 seconds without any optimise, but alteryx is take forever, so it may a good to use python sometimes. to reduce the run time.

Spoiler

part1: loop by 1 step (2 mins for 5k+ loops) > loop until it reach the block or out of map (9 seconds, for 160+ loops)
from here can see the macro is take long time to loop.

part2: use output from part1 (9 seconds * 5k = 12hrs~), logically, i don't run for it.

to reduce to 1hrs
1. log the path, so can have earlier escape when have same path appear.
2. start from the block -1 steps (so it not waste time to run until the new block, i.e. it not take 160 loops to go to last points)
3. split to 4 for AMP engine

Spoiler

iterative macro
Screenshot 2024-12-09 110011.png

to reduce to 10 mins
1. rework the nest macro, since part 2 no longer require record the maps, hence
a. keep the block ("#") only for (reduce the memory and data size to speed up)
b. just join by x/y and identify the if there have any block in front of the direction, if have turn 90 degree, if no, it is out of map.
(by change these method, it reduce half of tools)
2. use summary to count, instead of record count tools
3. split to 4 for AMP engine

workflow: Screenshot 2024-12-09 105937.png

batch macro
Screenshot 2024-12-09 105947.png

nested macro
Screenshot 2024-12-09 105954.png

Day 06.yxzp

Tokimatsu

Not smart, but it worked.

Spoiler

AoC2024_Day06_02.yxzp

lwolfie

Missed posting my solution for part 1. Things are getting busy, so I'm not sure how much further I'll get this year.

Day6.yxzp

aiahwieder

Stuck on 1 star again . . . sometimes you just gotta roll along!

Guard Gallivant_Pt1.yxzp

ccanterman

Ugly but got the job done! Part 2 took 1 hr, 47 min to run.

Spoiler

For Part 2, I created a Nested macro where I looked at each of the 5k squares that my guy steps in. I then basically said "if in square #1, he runs into a new obstacle and can't go to square #2 and instead turns to the right, will that new path be a loop?" I ran that new path through an iterative macro for a bunch of iterations (since the guard had the audacity to create a loop with more than a rectangle's worth of points - basically I wanted him to keep going until he went off the map. Then I knew it wasn't a loop). Once that point was done, I then said "if in square #2, he runs into a new obstacle" and just repeated.

Workflow:

Part 1 macro:

Part 2 macro - Outer macro (should've been a Batch but I did it as Iterative)

Inner macro:

Day 6.yxmd

SeanAdams

This is the beginning of the days where the runtime is horrendous - this one took multiple hours to run.

Spoiler

OK - how to approach this?
- Part 1 was an iterative macro - which passes on the iteration
- The grid, flattened into 1 row
- the current positoin
- the history of where I've been so that I can check for loops
- Part 2 then took the walk history from part 1 and checked each of these one by one to see if changing it to a blocker would cause a loop - I couldn't come up with a better way to do this quantitatively - I suspect that there's a smaller subset to check by just looking at where the same point is crossed multiple times, but not tested this idea.

Part 1:
Data prep was pretty large because on each iteration I'm packing and unpacking from the call stack (serialize / deserialize)

then the grid walker macro has this same complexity, both on the inbound and oubound side.
You'll also see that I have different outputs - one to track each position visited, one for the iteration, one if a loop is detected etc.

Part 2:
Part 2 is slow but not hard - all you do is use a batch macro to try each block once - and because the batch macro doesn't remember anything, it's much much simpler.

You can see that part 2 calls the part 1 grid walker for each new attempt.

This is very very slow - not proud of the speed, but it works :-)

Here's the python solution

All solutions at SeanAdams10/AdventOfCodePython: Advent of code challenges in Python - across multiple years

Day06.yxzp

SeanAdams

For everyone who has a working solution - esp @gawa and @CoG and @mmontgomery and @DataNath - have you run procmon to see what Alteryx is doing that causes it to run in such a long runtime compared to doing this in code. This is the key to helping Alteryx to optimize the power of macros. this is my next task for day 6, to figure out what's causing the run-time difference.

For example:
- Day 6 part 1 in Alteryx with AMP turned on (multi-threaded): 1m48 sec (yes - I am a bit bashful since others have done part 1 so quickly)

- Day 6 part 1 in code: 0.012 seconds on a single thread

that's a factor of 9000x. Even taking some of the faster runtimes posted by folk (like 1 sec or so) - that's still a factor of 100 difference with very heavy optimization

so there's something going on in each of our machines that is generating workload for the PC which may not be needed - this may be a really valuable example for us to dive into as a group to see if we can spot what's happening and create a few ideas on the community to performance tune macros.

here's a guide for how to get started with ProcMon:
https://chatgpt.com/share/6759637c-7fb0-8007-a05f-bfd08f0557f9

Gawa

@SeanAdams As I've been interested in the performance of AMP, thank you for sharing this toping.

When it comes to Iterative Macro, handover of iteration record from previous to next iteration should be one of the factor of slow running time, I suppose. As a first step, I investigated the running time of Day6P1 under the several conditions. I will figure out why running speed varies and what's going on with help of ProcMon (I installed ProcMon in my computer just now. Thank you for introducing it.).

Engine	1 process in Macro (164 iterations)	2 process in series in Macro (82 iterations)	3 process in series in Macro (54 iterations)
Non-AMP	2.1 sec	2.0 sec	2.0 sec
AMP	3.2 sec	2.2 sec	2.0 sec
AMP w/ compatibility mode	3.2 sec	2.2 sec	2.0 sec

Terminology:

'2 process in series in Macro' is to arrange the same process in series to reduce the necessary iteration number into half.

Likewise, '3 process in series in Macro' is like this. The necessary iteration number is one-third.

estherb47

After many different approaches and endless looping (a specialty of mine), I finally got Part 1 to run in 22.5 seconds.

Somewhere in the back of my mind, Digan was reminding me to minimize what I actually send through the iterative macro, so only sent the next location of the guard after moving (while outputting all of the steps taken in that movement)

More on this later. On to read Part 2.....