This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Instructions for part 1 were good. Part 2 made no sense to me. Took lots of discussion with other colleagues before I could make sense of it.
Seemed like a straighforward problem. Generate all the numbers between two given numbers (thank you Generate Rows tool!), and then make a really ugly filter to determine that the numbers are either the same left to right or increase.
Now to determine the adjacent numbers, I used a fun little RegEx trick: REGEX_CountMatches(tostring([Num1]), "([0-9])\1")>=1 This looks for any repetition of the same number.
Part 2 was challenging for me because I had trouble understanding which numbers were ok to have more than just a pair, and which weren't. Still not sure this was the best approach, but it did work in the end. I counted distinct numbers in each passcode that passed through part 1. and also counted how many times each number appeared in the passcode. To do this, parsed each number in each code out, and used some Summarizes, then joined back together.
An ugly formula determines if it meets the criteria for a passcode or not:
If [CountDistinct_Num1]=5 THEN "Y" ELSEIF [CountDistinct_Num1]=4 AND [Count]>2 THEN "N" ELSEIF [CountDistinct_Num1]=3 AND [Count]=4 THEN "N" ELSEIF [CountDistinct_Num1]=2 AND [Count] In (3,5) THEN "N" ELSEIF [CountDistinct_Num1]=1 THEN "N" ELSE "Y" ENDIF
Ultimately, anything with an N doesn't meet the criteria. Here's a snapshot. Happy solving!
I didn't realize that numeric references were supported in POSIX regex!! Since lookarounds aren't supported, I guess I just assumed that numeric references weren't either! So, I went with the very ugly regex below to find repeating digits:
Splitting characters into rows (as @cgoodman3 did)
On my laptop, splitting the characters into rows or columns using a parsing tool was consistently faster than parsing them within the filter. I wonder if the efficiency gain is due to running the parsing operation all at once (rather than parsing and comparing each record within the filter)?