Advent of Code 2024 Day 15 (BaseA Style)

[AlteryxCommunityTeam]

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

[gawa]

I'm happy to use Alteryx even in the weekend.

Spoiler

Part1: Applied Regex_Replace to create new location of objects. 

REGEX_Replace([Concat_Object], "(^.*#[^#]*?)(\.?)(O*@)$", "$1$3$2")​

Part2: Starting from "@", trace the objects until reaching to "#". I had to use nested Iterative Macro, and logic was complicate when moving upward or downward. 
To be honest, I admit my WFs still have much room of improvements. It takes too long time execution (30 min).  

 (EDIT)

Optimized my WF for Part2: 7minutes. I could not make it faster any more. 

[ntakeda]

My solution.

It takes about 7min.

Spoiler

Parts 1 and 2 are almost the same.
In part 2, I added a few more conditions.
 

 

[Tokimatsu]

In P1 I focused on the map and in P2 I focused on the object.

[mmontgomery]

Day15. More in spoiler

Spoiler

P1: Macro to build out each path: up, down, left, and right while checking to see if multiple can be moved at once
P2: It took a long time to figure out an approach. I knew I needed some dynamic logic to connect the vertical moving blocks that weren't aligned. My nested macro looks at the current point, next point, and next corresponding point (for instance if the next point was '[' the corresponding point would be ']' and then assigns the proper column. Then I'd loop through each combo until I hit a '#'. The results of this macro gave me all the data points affected by a vertical move. This allowed the block to move as one step and determine if they'd hit a '.' or a '#'. Left/right/up/down with no blocks impacted were the same from P1

17 min run time before I could optimize.

[Hub119]

This one was a bit of a beast... happy to have managed to get almost all of it done while riding shotgun for two long car rides yesterday as well... and special shoutout to my fiancé for driving and letting me work on Advent of Code.

Part 1 I approached essentially the exact same way I did Day 6 part 1 (for one time through at least with that guard it ran fairly quickly so thought I would try that route again).  Part 2 (once the new grid was prepped) I handled two different ways.  For horizontal movement I treated it the same way as part 1, for vertical movement I decided to focus in on the objects in the path and used an additional nested iterative macro to do the checks for surrounding "big box" pieces and walls they might run into.

Spoiler

Main Workflow

Spoiler

P1 Macro

Spoiler

P2 Main Macro

Spoiler

P2 Check Macro

[CoG]

This took way longer than I hoped it would. I kept constantly crashing into bugs that were often trivial to fix, but difficult to find. I built a mechanism to capture all states of the map, and generated a video file to watch the robot on its route in the sample data to make sure nothing weird was happening... But that's all behind me now. No fancy algorithms, just good old fashioned brute force (with limited optimizations as well):

Spoiler

Move Robot Macro:


Helper macro to identify all vertically connected boxes that need to move as unit:

[AkimasaKajitani]

Finally, solved!

This is the one of the most difficult puzzle this year for me.

Spoiler

This workflow is definitely not a reference, it's like a patchwork effort as I couldn't find a good algorithm.



Part 1:
This is simple workflow.


Part 2:
Part 2 macro is too many tool and very complex workflow. Definitely the most complex workflow of the year. Horizontal direction algorithm is the same as part 1. But vertical direction is very messy.

The vertical algorithm consists of three parts. The first is an algorithm that extracts all objects in the direction of pushing the luggage from the starting point(@). The second identifies the luggage to be pushed. The third determines whether pushing will result in a collision with a wall.
Parts 1 and 2 are macros.


#1(Search object macro)

This macro extract the data as follows(blue box).


#2(Identify the luggage to push)

In the past, I missed the situation below. So, I create this macro. This macro is to solve that situation.



My first algorythm is not considered about orange blocks becase the X-axis push process was only performed once. I am using a iterative macro to group blocks repeatedly.

[PangHC]

it difficult to find where the bug. it worked in sample but not the input.

Spoiler

part1: just follow the instructions

part2: just change on ^v, (<> is same rules as above)

use nested macro to check if [ or ] then add one right/left cells.
check until any of it blocks (or escape when all meet empty space)

i faced bugs below:
1. when have hole in middle, it ignore the middle space
[][].
[].[]
[][].
.[]..
..@..

2. when have hole in side, it ignore the space
[][
[].
[][
.[]
..@

[DaisukeTsuchiya]

Day15P2 was one of the most challenging problems to solve in this year’s AoC.

Spoiler

In P1, there were 20,000 loops, and initially, history was maitained, which caused errors in Alteryx. The box positions were swapped using regular expressions, but the processing in P1 was somewhat redundant.

For P2, I gave up reusing P1 and decided to rebuild it from scratch. After considerable thought, I referred to @Tokimatsu  's workflow for inspiration. By representing only the left side of "O" and "#" as representative points without actually increasing the "O" and "#", significant simplification was achieved.

First, a mapping table was created in Excel by drawing a diagram of which range of cells would be affected when "@" or "O" moved. When "@" moved, the influence range of the pushed cells were calculated. If there was a "#" within the range, the move was canceled; if there was no "#", a macro updated the positions of "@" and "O".

P1 took about 10 minutes to execute, and P2 took about 8 minutes.


<P1 Macro>

<P2 Macro to check the pushed cell>

<P2 Main Macro>