Wow, the 384 char version is much faster than the 504 and only about half the speed as the 537 (this is assuming RME does the optimization it currently doesn't), but the 379 char version is hugely slower. Interesting. I'll bet that introducing an optimization that looks past negative lookaheads to evaluate the faster condition that follows them first would bring back the speed.
For example making (?!(xx+)(?!\16+$)\18+$) act like (?!(xx+)(?=\18+$)(?!\16+$))
Hmm actually 381 might've already been slow, in which case what caused it was 384->382 (I didn't post or save the 382, but 382->381 is trivial, just changing two () to (?:))
(When I remove a paren pair, I always remove the closing paren that matched the opening paren, even when multiple consecutive closing parens make that irrelevant)
And (?=\6((x+?)\1+$)) -> (?=\6((x+?)(?=\1+$).*)) is the edit that makes it behave as it would be RME had the optimization I plan on giving it
@Grimy I don't always do that. But sometimes I copy and paste something short rather than retyping it, just to be 100% sure instead of 99.999% sure there's no typo.
And yeah jumping number would've been cool as a decision problem
If you remove the initial ^, given the nth term of the sequence, the regex outputs n (via the number of matches), but that's still backwards compared to what's asked
Regex (ECMAScript), 60 bytes
The input \$n\$ is in unary, as the length of a string of xs.
This works by finding \$z=2^{\lfloor log_2{n}\rfloor}\$ (the largest power of 2 not exceeding \$n\$), then asserting that \$z\$ is a perfect square while taking its square root, and finally asserting that...
$ seq 10 | regex --verbose -nx 'x$'
1 -> 1
2 -> no match
3 -> no match
4 -> no match
5 -> no match
6 -> no match
7 -> no match
8 -> no match
9 -> no match
10 -> no match
BTW, that explains why it'd still be broken with -O0. In that mode it probably intentionally initializes uninitialized variables with a test pattern.
And this bug only happens for test inputs after the first input.
Because virtualizeSymbols() initializes the "anchored" variable, but the symbol virtualization is subsequently cached and doesn't need to be recalculated, but a fresh RegexMatcher object is created for each input, thus "reinitializing" the "anchored" variable
C (gcc), 26 bytes
f(n){n=~n==(n^=-~n)*~n/2;}
Try it online!
Port of Neil's answer. Relies on implementation-defined ordering of operations.
C++ (gcc), 34 bytes
int f(int n){n=~n==(n^=-~n)*~n/2;}
Try it online!
Can't omit the types in C++, otherwise identical.
Here is my Cyclops regex: ^((?=x(x*?)\2(?=(x+)\3$)((x+)(?=\5$))*x$)\3\3(?=\3)x\2)*x{5}$. (61 bytes, doesn't match 0). Possibly improbable, but I'm on my phone. If anyone finds improvements, feel free to hijack it
@H.PWiz Interesting! I think Grimy used a similar method for his first solution (step down consecutively through the smaller cyclops numbers until reaching 5) but his was 65 bytes. However, note that we didn't know at that point that zero was required to return truthy, so his 65 would really be 68 and your 60 is really 63 due to the needed |^$.
Regex (ECMAScript), 60 bytes
The input \$n\$ is in unary, as the length of a string of xs.
This works by finding \$z=2^{\lfloor log_2{n}\rfloor}\$ (the largest power of 2 not exceeding \$n\$), then asserting that \$z\$ is a perfect square while taking its square root, and finally asserting that...
C (gcc), 26 bytes
f(n){n=~n==(n^=-~n)*~n/2;}
Try it online!
Port of Neil's answer. Relies on implementation-defined ordering of operations.
C++ (gcc), 34 bytes
int f(int n){n=~n==(n^=-~n)*~n/2;}
Try it online!
Can't omit the types in C++, otherwise identical.
