Regex (.NET) + x
flag, 418 209 204 199 132 115 99 bytes
-209 bytes (418 → 209) thanks to Neil
(\5$|(.*(?=(0.*1|1.*2|2.*3|3.*4|4.*5|5.*6|6.*7|7.*8|8.*9)(?<=(.)))|(?=9+(?<4>1))).9*(?=(\2\4 0*)))*
Returns its result as the list of captures on the Balancing Group 1 stack.
Try it online!
# Main loop - Iterates once for each matched number in the squashed sequence.
# There is no need to anchor, because the input is guaranteed to be valid.
( # \1 = push matched number onto the Group 1 stack
\5$ # Stop immediately if the previous iteration identified
# this as being next, and there is nothing following it.
|
# Using greedy quantifiers, the following, up to and including "9*",
# matches the number with as many digits as possible that is followed by
# the next consecutive number.
( # \2 = the prefix portion of the number that won't
# change when incremented
.*
(?=
# Depending on this next digit, capture its incremented form in \4.
# Only digits that do not carry when incremented are handled here.
(
0.*1 |
1.*2 |
2.*3 |
3.*4 |
4.*5 |
5.*6 |
6.*7 |
7.*8 |
8.*9
)
(?<=(.)) # \4
)
|
# Treat a prefix of all 9s as a special case, because when incremented
# it will be one digit longer, e.g. 999 -> 1000. In this case, \2 will
# be empty.
(?=
9+
(?<4>1) # \4 - Technically this should capture "10", but since
# our input is guaranteed to be valid, we can
# assume that the "0*" below will match the
# correct number of zeroes.
)
)
. # Skip over the first digit that will be different when
# incremented.
9* # Skip over the portion that will become all 0s when
# incremented.
# Match the next consecutive number. This constraint is what tells the
# above how many digits to match.
(?=
( # \5 = Capture the next number. This allows the last
# number in the sequence to be matched as a whole
# unambiguously, in case its digits form their own
# "nested" squashed sequence.
\2
\4 # Note that since this is followed by a "0", to get
# this to parse correctly we could either concatenate
# them as "\4[0]*", or enable the /x flag (ignore
# whitespace) and use "\4 0*".
0* # Technically this should match the same number of 0s
# however many 9s were matched by "9*" above, but since
# our input is guaranteed to be valid, we can assume it
# will do this without being forced, since none of the
# numbers in the sequence will have leading zeroes.
)
)
)* # Iterate as many times as possible, with minimum zero.
Solving this problem is a bit verbose in pure regex, since it has no concept of alphanumeric/ASCII order or sorting. So each digit needs to be handled as a separate case.
Rejecting invalid input takes 138 bytes: ^(\6$|(?!0)(.*(?=(0.*1|1.*2|2.*3|3.*4|4.*5|5.*6|6.*7|7.*8|8.*9)(?<=(.)))|(?=9+(?<4>10))).(9)*(?=(?(7)\7))(?=(\2\4(?<-5>0)*(?(5)^))(.*)))*$
Regex (PCRE) + x
flag, 107 bytes
(\4$|(?|(.*)(?=(?:0.*1|1.*2|2.*3|3.*4|4.*5|5.*6|6.*7|7.*8|8.*9)(?<=(.)))|()(?=9+(1))).9*(?=(\2\3 0*))(?C))*
Returns its result using a (?C)
callout to report each split point (the number of split points will be one less than the number of consecutive integers).
Try it online! - PCRE1
Try it online! - PCRE2 v10.33
Attempt This Online! - PCRE2 v10.40+
This is a straightforward port of the .NET version.
# Main loop - Iterates once for each matched number in the squashed sequence.
# There is no need to anchor, because the input is guaranteed to be valid.
(
\4$ # Stop immediately if the previous iteration identified
# this as being next, and there is nothing following it.
|
# Using greedy quantifiers, the following, up to and including "9*",
# matches the number with as many digits as possible that is followed by
# the next consecutive number.
(?|
(.*) # \2 = the prefix portion of the number that won't
# change when incremented
(?=
# Depending on this next digit, capture its incremented form in \3.
# Only digits that do not carry when incremented are handled here.
(?:
0.*1 |
1.*2 |
2.*3 |
3.*4 |
4.*5 |
5.*6 |
6.*7 |
7.*8 |
8.*9
)
(?<=(.)) # \3
)
|
# Treat a prefix of all 9s as a special case, because when incremented
# it will be one digit longer, e.g. 999 -> 1000. In this case, \2 will
# be empty.
() # \2 = empty prefix
(?=
9+
(1) # \3 - Technically this should capture "10", but since
# our input is guaranteed to be valid, we can
# assume that the "0*" below will match the
# correct number of zeroes.
)
)
. # Skip over the first digit that will be different when
# incremented.
9* # Skip over the portion that will become all 0s when
# incremented.
(?=
( # \4 = Capture the next number. This allows the last
# number in the sequence to be matched as a whole
# unambiguously, in case its digits form their own
# "nested" squashed sequence.
\2
\3 # Note that since this is followed by a "0", to get
# this to parse correctly we could either concatenate
# them as "\3[0]*", or enable the /x flag (ignore
# whitespace) and use "\3 0*".
0* # Technically this should match the same number of 0s
# however many 9s were matched by "9*" above, but since
# our input is guaranteed to be valid, we can assume it
# will do this without being forced, since none of the
# numbers in the sequence will have leading zeroes.
)
)
(?C) # PCRE callout - report each split point to the caller
)*
Rejecting invalid input is not so straightforward to port from the .NET version, and takes 175 bytes: ^(?>\7$((9(?=9*\4\5(\3?+0)))*(?=(?(6)\6))\4\5\3?+)?|(?|(?!0)(.*)(?=(?:0.*1|1.*2|2.*3|3.*4|4.*5|5.*6|6.*7|7.*8|8.*9)(?<=(.)))|()(?=9+(10))).(?=(?1)(.*))9*(?=(\4\5 0*)\6)(?C))*$
Regex (PCRE2) + x
flag, 166 bytes
(?=(.*))(?:^(?3)|((?<=(?=^((?|(.*)(?=(?:0.*1|1.*2|2.*3|3.*4|4.*5|5.*6|6.*7|7.*8|8.*9)(?<=(.)))|()(?=9+(1))).9*(?=(\4\5 0*)))*(?=\1$)(?>\6$|)(?(?=$)^)|(?2)).))(?3)|.+)
Returns its result as the list of individual matches.
Attempt This Online!
A lot of overhead is added to achieve this output method. Captures are not preserved from one individual match to the next, thus to avoid incorrectly splitting the last number, the regex must look all the way back to the start, then parse forward from there, for each individual match. There's no variable-length lookbehind in PCRE2, so it is emulated using recursion.
[6, 667]
would be a valid answer too right? \$\endgroup\$9101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100
, so programs that take an integer as input could employ a shortcut in their design such that they could detect only up to one such increment. Would such a shortcut be accepted as valid? \$\endgroup\$