Return to Answer

This regex takes advantage of the (?<name1-name2>pattern) syntax for golf reasons, using it as an equivalent for (?<-name2>)(?<name1>). It makes sure to only do this when the cursor is at the beginning of the input string, so that only empty values are pushed onto \k<name1>. This is used in two places, and the first instance only works in RegexOptions.Compiled mode; without it, the above-described exception is thrown with inputs \$\ge 21\$, probably because some of the 1円 empties it pops were captured from elsewhere than the beginning of the string. A third potential place for this trick would seem to be (?<-2>2円)(?<3>), but if an attempt is made to convert it from (?=.*$((?<-2>2円)(?<3>)|){9}) to (?<=((?<3-2>2円)|){9}^.*), the exception is thrown regardless of mode. Seeing as there's no debugger for .NET regex, it would be tricky to dig deeper into the conditional nature of this error.

This regex takes advantage of the (?<name1-name2>pattern) syntax for golf reasons, using it as an equivalent for (?<-name2>)(?<name1>). It makes sure to only do this when the cursor is at the beginning of the input string, so that only empty values are pushed onto \k<name1>. This is used in two places, and the first instance only works in RegexOptions.Compiled mode; without it, the above-described exception is thrown with inputs \$\ge 21\$, probably because some of the 1円 empties it pops were captured from elsewhere than the beginning of the string. A third potential place for this trick would seem to be (?<-2>2円)(?<3>), but if an attempt is made to convert it from (?=.*$((?<-2>2円)(?<3>)|){9}) to (?<=((?<3-2>2円)|){9}^.*), the exception is thrown regardless of mode. Seeing as there's no debugger for .NET regex, it would be tricky to dig deeper into the conditional nature of this error.

I had already written a .NET regex to match primes in decimal a couple weeks before, but it must be given a hard-coded maximum bound. It's 192 bytes in length (and isn't shortened by reducing its limit from \999ドル\$ to \255ドル\$, but is shortened to 189 bytes by dropping zero-handling, and does its calculations in unary, after converting the decimal input to unary. (Its numeric variables are represented by the number of captures on each stack, being agnostic to the contents of the captures.) At the time, I thought it would be impossible to do this without a bound.

I had already written a .NET regex to match primes in decimal a couple weeks before, but it must be given a hard-coded maximum bound. It's 192 bytes in length (and isn't shortened by reducing its limit from \999ドル\$ to \255ドル\$, but is shortened to 189 bytes by dropping zero-handling ), and does its calculations in unary, after converting the decimal input to unary. (Its numeric variables are represented by the number of captures on each stack, being agnostic to the contents of the captures.) At the time, I thought it would be impossible to do this without a bound.

This regex takes advantage of the (?<name1-name2>pattern) syntax for golf reasons, using it as an equivalent for (?<-name2>)(?<name1>). It makes sure to only do this when the cursor is at the beginning of the input string, so that only empty values are pushed onto \k<name1>. This is used in two places, and I currently do not know why the first instance is working, instead of throwing the above-described exception [Edit: regex101 now supports the (?<name1-name2>) syntax, and actually throws the error there – see below]; it seems to be that at least some of the 1円 empties it pops would have been captured from elsewhere than the beginning of the string. The (?<-2>2円)(?<3>) does in fact throw this exception if an attempt is made to convert it from (?=.*$((?<-2>2円)(?<3>)|){9}) to (?<=((?<3-2>2円)|){9}^.*). As far as I know there's no debugger for .NET regex, so it may be tricky to get to the bottom of this.

*regex101 is actually throwing an error like my reasoning said should happen when using the (?<5-1>1円) shorthand trick. Whether that's due to it running the latest version of .NET, or executing the regex in a stricter manner (perhaps due to reading the values of captures during execution), I have not yet determined. Here is commented view of the section modified to avoid this error (making it 4 bytes longer):

This regex takes advantage of the (?<name1-name2>pattern) syntax for golf reasons, using it as an equivalent for (?<-name2>)(?<name1>). It makes sure to only do this when the cursor is at the beginning of the input string, so that only empty values are pushed onto \k<name1>. This is used in two places, and the first instance only works in RegexOptions.Compiled mode; without it, the above-described exception is thrown with inputs \$\ge 21\$, probably because some of the 1円 empties it pops were captured from elsewhere than the beginning of the string. A third potential place for this trick would seem to be (?<-2>2円)(?<3>), but if an attempt is made to convert it from (?=.*$((?<-2>2円)(?<3>)|){9}) to (?<=((?<3-2>2円)|){9}^.*), the exception is thrown regardless of mode. Seeing as there's no debugger for .NET regex, it would be tricky to dig deeper into the conditional nature of this error.

*regex101 doesn't make it possible to enable the Compiled flag, so it throws the error in versions that use the (?<5-1>1円) shorthand. Here is commented view of the section modified to avoid this error (making it 4 bytes longer):