Advent of Code 2023 Day 19 (BaseA Style)

[AlteryxCommunityTeam]

Discussion thread for day 19 of the Advent of Code - https://adventofcode.com/2023/day/19

[CoG]

This problem was a ton of fun, especially Part 2. It seems I really enjoy working with ranges (it's like generating a spider's web). At first, I was intimidated by Part 2, but once I got into the flow and started putting things together, it all came together beautifully (I didn't even have to debug Part 2's workflow at all)!

I will post my exported workflow later

Edit: Added my workflow

Algorithm:

Spoiler

Part 1 is fairly straight forward. I used an iterative macro to track which rule a given part was working its way through (iterating on the entire list of parts). I used a Formula Tool with a lot of IIF's to handle the dynamic condition logic, generating all the output from each step of a rule (including Null() if a condition was not met). This allowed me to get the proper output by finding the first non-null value in the list of steps for a given rule. After the Iterative macro completed, all that's left to do is sum up all the values of all Accepted parts and your done!

Part 2 is where things get interesting. Brute force is (yet again) not feasible unless you can get your hands on a quantum computer and figure out how to build a workflow there. Since this is a counting problem, we can employ some basic principles of combinatorics and number theory. Namely, the total number of all possible independent variables is the product of all possible values for each variable. In this problem, if the only rule was in{A} then all parts are accepted by default with a total count of 4000*4000*4000*4000.

Naturally, we aren't that lucky, and so we must determine which ranges of values will be Accepted and which Rejected, working on a more granular scale, until we reach the end and can aggregate back to our answer and receive our sweet, sweet AoC star.

In order to keep track of ranges, we need a way of tracking them. I opted to track the Min and Max of each variable { 's', 'a', 'x', 'm' }, which used 8 columns, and lends itself to a very clear starting point for the nested iterative macro that will do the heavy lifting for us:

Min S	Max S	Min A	Max A	Min X	Max X	Min M	Max M	Rule
1	4000	1	4000	1	4000	1	4000	in

in order to evaluate and break down the ranges, I built a second nested iterative macro that iterates through the steps of a rule and determines which range of values satisfies the condition and which do not (those that do not will re-iterate until no range remains or the Else condition is reached).
Example Rule: in{ m < 2000:A, R }

Iteration 1: Matches values 'm' < 2000, which would output:

Min S	Max S	Min A	Max A	Min X	Max X	Min M	Max M	Rule
1	4000	1	4000	1	4000	1	1999	A

Leaving behind for the second and final iteration (Else condition):

Min S	Max S	Min A	Max A	Min X	Max X	Min M	Max M	Rule
1	4000	1	4000	1	4000	2000	4000	R

We would now have two records iterating through our outer macro, which would consequently end due to reaching A/R for all records.

Once the macros finish subdividing our ranges, we will be left with a list of range combinations that are either Accepted or Rejected. Filter for Accepted and Multiply the range for each individual variable (Max - Min + 1) * ...

Well Done if you managed to solve. These are tricky problems and can be challenging to wrap your head around!

Workflow:

Spoiler

Main:

Iterative Macro (Part 1):

Iterative Macro (Part 2):

Nested Iterative Macro (Part 2; separates ranges according to rules):

[gawa]

I realized I frequently switch sample<=>input data, and to do so, disconnect and connect the line again and again. As I'm tired of this process, created switching macro as attached. If you feel the same thing, please use it.(I cannot take responsibility if you have wrong answer by some error of this macro😅 believe it does not... 

BTW, D19 was a bit tough one, but interesting. 

Spoiler

[ScottLewis]

Liked this one because it made me think about how I build.

This is really just case management and string parsing, excepting that it is hard versions of both those things. 

For case management problems I like to build in an inefficient way. Rather than trying to manage cases in formulas or collapse them into macros I lay out branching paths and fill them in as the cases occur in the data and then eventually once I can see all the patterns fill in the rest. I do a lot of copy/paste and simple formula edits (simple because of consistent field names.) The end result is something like the part2 (RangeSort) Macro. If I was going to put something like this into production I would look at collapsing some of the paths and likely writing a second tier macro that did a single rule without having to know where it was in the instruction but for prototyping (which is really what advent is) I prefer to forgo inefficiency. As a bonus you end up with beautifully monstrous workflows.

Also an interesting window into how much efficiency increases when you're not watching a workflow run. My part 2 runs for a bout 3 seconds to do the third iteration. If I instead run the whole of part 2 from the main workflow the macro runs every iteration in less than a second. 

 

[Qiu]

I know Dynamic Replace will be a good fit for the Criterias, but just have not made it working. 😁

[phottovy]

Fun challenge except I messed up the logic cleaning up my workflow to post 😅

Spoiler

Simply Outer Macro:


Nested Macro:

[PangHC]

think of range but still cant figure it. 

thanks @CoG 

Spoiler

similar concept. just less tools.

use multi-field tools to reduce the number of tools. but it may hard to understand by others.  

part2 macro

part2 macro's macro

include formula:

if right([_CurrentFieldName_],1)=[variable] then
  if [operator]=">" then
    if contains([_CurrentFieldName_],"Min") then
        [amount]+1
    else
        [_CurrentField_]
    endif
  elseif [operator]="<" then 
    if contains([_CurrentFieldName_],"Max") then
        [amount]-1
    else
        [_CurrentField_]
    endif
  else
    [_CurrentField_]
  endif
else
  [_CurrentField_]
endif​

exclude/ else formula

if right([_CurrentFieldName_],1)=[variable] then
  if [operator]="<" then
    if contains([_CurrentFieldName_],"Min") then
        [amount]
    else
        [_CurrentField_]
    endif
  elseif [operator]=">" then 
    if contains([_CurrentFieldName_],"Max") then
        [amount]
    else
        [_CurrentField_]
    endif
  else
    [_CurrentField_]
  endif
else
  [_CurrentField_]
endif

[DaisukeTsuchiya]

P2 is difficult for me.

Spoiler

It took long time to make logic for P2. I recreate WF again and again and hought to quit many times.
Now it becomes fun and favorite problem once it is completed.
<Main WF>


<P1 Macro>


<P2 Macro>

[AkimasaKajitani]

This is needed the complex logic.

Spoiler

Part 1 macro : To simple the logic, I put the many macro input tools.

Part 1 workflow.

Part 2:

The start is only quize workflow.

 

Based on that, I make the all pattern but not judge. To do this, I use the fowllowing macro.

The result is as following. This is 1.

Separately, I applied conditions to each tag. The first line is the same condition, but the next line reverses the condition. As you go down, the processing of the previous row is reversed, and further rows are stacked. Let's call this 2.

 

And then, I got all condition from 1 and 2.

When I got the table bellow, it's like I got the answer.

 

Final workflow:

 

 

[Tokimatsu]

Long way to solve part2.  

Spoiler